From: Philip Reames Date: Tue, 1 Nov 2022 16:33:32 +0000 (-0700) Subject: [RISCV][docs] Add some wording around vendor extensions X-Git-Tag: upstream/17.0.6~28838 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=9395b98ba03efd90d09a78d4ada9a2f99ba999b8;p=platform%2Fupstream%2Fllvm.git [RISCV][docs] Add some wording around vendor extensions This adds an initial bit of policy around inclusion of vendor extensions. My intention here is to leave all of the actual decision making to a case by case decision on the regular sync calls, but to spell out some of the pieces we've discussed and (I think) have general agreement on. Differential Revision: https://reviews.llvm.org/D136968 --- diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst index 387f2c2..6506d75 100644 --- a/llvm/docs/RISCVUsage.rst +++ b/llvm/docs/RISCVUsage.rst @@ -146,6 +146,18 @@ The primary goal of experimental support is to assist in the process of ratifica To use an experimental extension from `clang`, you must add `-menable-experimental-extensions` to the command line, and specify the exact version of the experimental extension you are using. To use an experimental extension with LLVM's internal developer tools (e.g. `llc`, `llvm-objdump`, `llvm-mc`), you must prefix the extension name with `experimental-`. Note that you don't need to specify the version with internal tools, and shouldn't include the `experimental-` prefix with `clang`. +Vendor Extensions +================= + +Vendor extensions are extensions which are not standardized by RISC-V International, and are instead defined by a hardware vendor. At the moment, LLVM does not support any vendor extensions for RISC-V, but we expect this to change in the future. + +The term vendor extension roughly parallels the definition of a `non-standard` extension from Section 1.3 of the Volume I: RISC-V Unprivileged ISA specification. In particular, we expect to eventually accept both `custom` extensions and `non-conforming` extensions. + +Inclusion of a vendor extension will be considered on a case by case basis. All proposals should be brought to the bi-weekly RISCV sync calls for discussion. For a general idea of the factors likely to be considered, please see the `Clang documentation `_. + +It is our intention to follow the naming conventions described in `riscv-non-isa/riscv-toolchain-conventions `_. Exceptions to this naming will need to be strongly motivated. + + Specification Documents ======================= For ratified specifications, please refer to the `official RISC-V International