User Guide for RISC-V Target¶
Introduction¶
The RISC-V target provides code generation for processors implementing
supported variations of the RISC-V specification. It lives in the
llvm/lib/Target/RISCV directory.
Specification Documents¶
There have been a number of revisions to the RISC-V specifications. LLVM aims to implement the most recent ratified version of the standard RISC-V base ISAs and ISA extensions with pragmatic variances. The most recent specification can be found at: https://github.com/riscv/riscv-isa-manual/releases/.
The official RISC-V International specification page. is also worth checking, but tends to significantly lag the specifications linked above. Make sure to check the wiki for not yet integrated extensions and note that in addition, we sometimes carry support for extensions that have not yet been ratified (these will be marked as experimental - see below) and support various vendor-specific extensions (see below).
The current known variances from the specification are:
Unconditionally allowing instructions from zifencei, zicsr, zicntr, and zihpm without gating them on the extensions being enabled. Previous revisions of the specification included these instructions in the base ISA, and we preserve this behavior to avoid breaking existing code. If a future revision of the specification reuses these opcodes for other extensions, we may need to reevaluate this choice, and thus recommend users migrate build systems so as not to rely on this.
Allowing CSRs to be named without gating on specific extensions. This applies to all CSR names, not just those in zicsr, zicntr, and zihpm.
The ordering of
z*,s*, andx*prefixed extension names is not enforced in user-specified ISA naming strings (e.g.-march).
We are actively deciding not to support multiple specification revisions at this time. We acknowledge a likely future need, but actively defer the decisions making around handling this until we have a concrete example of real hardware having shipped and an incompatible change to the specification made afterwards.
Base ISAs¶
The specification defines five base instruction sets: RV32I, RV32E, RV64I, RV64E, and RV128I. Currently, LLVM fully supports RV32I, and RV64I. RV32E and RV64E are supported by the assembly-based tools only. RV128I is not supported.
To specify the target triple:
RISC-V Architectures¶ Architecture
Description
riscv32RISC-V with XLEN=32 (i.e. RV32I or RV32E)
riscv64RISC-V with XLEN=64 (i.e. RV64I or RV64E)
To select an E variant ISA (e.g. RV32E instead of RV32I), use the base
architecture string (e.g. riscv32) with the extension e.
Extensions¶
The following table provides a status summary for extensions which have been ratified and thus have finalized specifications. When relevant, detailed notes on support follow.
Ratified Extensions by Status¶ Extension
Status
ASupported
CSupported
DSupported
FSupported
ESupported (See note)
HAssembly Support
MSupported
SmaiaSupported
SmepmpSupported
SsaiaSupported
SvinvalAssembly Support
SvnapotAssembly Support
SvpbmtSupported
VSupported
Za128rsSupported (See note)
Za64rsSupported (See note)
ZawrsAssembly Support
ZbaSupported
ZbbSupported
ZbcSupported
ZbkbSupported (See note)
ZbkcSupported
ZbkxSupported (See note)
ZbsSupported
ZcaSupported
ZcbSupported
ZcdSupported
ZcfSupported
ZcmpSupported
ZcmtAssembly Support
ZdinxSupported
ZfaSupported
ZfhSupported
ZfhminSupported
ZfinxSupported
ZhinxSupported
ZhinxminSupported
Zic64bSupported (See note)
ZicbomAssembly Support
ZicbopSupported
ZicbozAssembly Support
ZiccamoaSupported (See note)
ZiccifSupported (See note)
ZicclsmSupported (See note)
ZiccrseSupported (See note)
Zicntr(See Note)
ZicondSupported
Zicsr(See Note)
Zifencei(See Note)
ZihintntlSupported
ZihintpauseAssembly Support
Zihpm(See Note)
ZknSupported
ZkndSupported (See note)
ZkneSupported (See note)
ZknhSupported (See note)
ZksedSupported (See note)
ZkshSupported (See note)
ZkSupported
ZkrSupported
ZksSupported
ZktSupported
ZmmulSupported
ZvbbAssembly Support
ZvbcAssembly Support
Zve32x(Partially) Supported
Zve32f(Partially) Supported
Zve64xSupported
Zve64fSupported
Zve64dSupported
ZvfhSupported
ZvkbAssembly Support
ZvkgAssembly Support
ZvknAssembly Support
ZvkncAssembly Support
ZvknedAssembly Support
ZvkngAssembly Support
ZvknhaAssembly Support
ZvknhbAssembly Support
ZvksAssembly Support
ZvkscAssembly Support
ZvksedAssembly Support
ZvksgAssembly Support
ZvkshAssembly Support
ZvktAssembly Support
Zvl32b(Partially) Supported
Zvl64bSupported
Zvl128bSupported
Zvl256bSupported
Zvl512bSupported
Zvl1024bSupported
Zvl2048bSupported
Zvl4096bSupported
Zvl8192bSupported
Zvl16384bSupported
Zvl32768bSupported
Zvl65536bSupported
- Assembly Support
LLVM supports the associated instructions in assembly. All assembly related tools (e.g. assembler, disassembler, llvm-objdump, etc..) are supported. Compiler and linker will accept extension names, and linked binaries will contain appropriate ELF flags and attributes to reflect use of named extension.
- Supported
Fully supported by the compiler. This includes everything in Assembly Support, along with - if relevant - C language intrinsics for the instructions and pattern matching by the compiler to recognize idiomatic patterns which can be lowered to the associated instructions.
ESupport of RV32E/RV64E and ilp32e/lp64e ABIs are experimental. To be compatible with the implementation of ilp32e in GCC, we don’t use aligned registers to pass variadic arguments. Furthermore, we set the stack alignment to 4 bytes for types with length of 2*XLEN.
Zbkb,ZbkxPattern matching support for these instructions is incomplete.
Zknd,Zkne,Zknh,Zksed,ZkshNo pattern matching exists. As a result, these instructions can only be used from assembler or via intrinsic calls.
Zve32x,Zve32f,Zvl32bLLVM currently assumes a minimum VLEN (vector register width) of 64 bits during compilation, and as a result
Zve32xandZve32fare supported only for VLEN>=64. Assembly support doesn’t have this restriction.
zicntr,zicsr,zifencei,zihpmBetween versions 2.0 and 2.1 of the base I specification, a backwards incompatible change was made to remove selected instructions and CSRs from the base ISA. These instructions were grouped into a set of new extensions, but were no longer required by the base ISA. This change is partially described in “Preface to Document Version 20190608-Base-Ratified” from the specification document (the
zicntrandzihpmbits are not mentioned). LLVM currently implements version 2.1 of the base specification. To maintain compatibility, instructions from these extensions are accepted without being in the-marchstring. LLVM also allows the explicit specification of the extensions in an-marchstring.
Za128rs,Za64rs,Zic64b,Ziccamoa,Ziccif,Zicclsm,ZiccrseThese extensions are defined as part of the RISC-V Profiles specification. They do not introduce any new features themselves, but instead describe existing hardware features.
Experimental Extensions¶
LLVM supports (to various degrees) a number of experimental extensions. All experimental extensions have experimental- as a prefix. There is explicitly no compatibility promised between versions of the toolchain, and regular users are strongly advised not to make use of experimental extensions before they reach ratification.
The primary goal of experimental support is to assist in the process of ratification by providing an existence proof of an implementation, and simplifying efforts to validate the value of a proposed extension against large code bases. Experimental extensions are expected to either transition to ratified status, or be eventually removed. The decision on whether to accept an experimental extension is currently done on an entirely case by case basis; if you want to propose one, attending the bi-weekly RISC-V sync-up call is strongly advised.
experimental-zacasLLVM implements the 1.0-rc1 draft specification.
experimental-zfbfmin,experimental-zvfbfmin,experimental-zvfbfwmaLLVM implements assembler support for the 1.0.0-rc2 specification.
experimental-zicfilp,experimental-zicfissLLVM implements the 0.4 draft specification.
experimental-ztsoLLVM implements the v0.1 proposed specification (see Chapter 25). The mapping from the C/C++ memory model to Ztso has not yet been ratified in any standards document. There are multiple possible mappings, and they are not mutually ABI compatible. The mapping LLVM implements is ABI compatible with the default WMO mapping. This mapping may change and there is explicitly no ABI stability offered while the extension remains in experimental status. User beware.
experimental-zimopLLVM implements the v0.1 proposed specification.
experimental-zcmopLLVM implements the v0.2 proposed specification.
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. 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.
The current vendor extensions supported are:
XTHeadBaLLVM implements the THeadBa (address-generation) vendor-defined instructions specified in by T-HEAD of Alibaba. Instructions are prefixed with th. as described in the specification.
XTHeadBbLLVM implements the THeadBb (basic bit-manipulation) vendor-defined instructions specified in by T-HEAD of Alibaba. Instructions are prefixed with th. as described in the specification.
XTHeadBsLLVM implements the THeadBs (single-bit operations) vendor-defined instructions specified in by T-HEAD of Alibaba. Instructions are prefixed with th. as described in the specification.
XTHeadCondMovLLVM implements the THeadCondMov (conditional move) vendor-defined instructions specified in by T-HEAD of Alibaba. Instructions are prefixed with th. as described in the specification.
XTHeadCmoLLVM implements the THeadCmo (cache management operations) vendor-defined instructions specified in by T-HEAD of Alibaba. Instructions are prefixed with th. as described in the specification.
XTHeadFMemIdxLLVM implements the THeadFMemIdx (indexed memory operations for floating point) vendor-defined instructions specified in by T-HEAD of Alibaba. Instructions are prefixed with th. as described in the specification.
XTheadMacLLVM implements the XTheadMac (multiply-accumulate instructions) vendor-defined instructions specified in by T-HEAD of Alibaba. Instructions are prefixed with th. as described in the specification.
XTHeadMemIdxLLVM implements the THeadMemIdx (indexed memory operations) vendor-defined instructions specified in by T-HEAD of Alibaba. Instructions are prefixed with th. as described in the specification.
XTHeadMemPairLLVM implements the THeadMemPair (two-GPR memory operations) vendor-defined instructions specified in by T-HEAD of Alibaba. Instructions are prefixed with th. as described in the specification.
XTHeadSyncLLVM implements the THeadSync (multi-core synchronization instructions) vendor-defined instructions specified in by T-HEAD of Alibaba. Instructions are prefixed with th. as described in the specification.
XTHeadVdotLLVM implements version 1.0.0 of the THeadV-family custom instructions specification by T-HEAD of Alibaba. All instructions are prefixed with th. as described in the specification, and the riscv-toolchain-convention document linked above.
XVentanaCondOpsLLVM implements version 1.0.0 of the VTx-family custom instructions specification by Ventana Micro Systems. All instructions are prefixed with vt. as described in the specification, and the riscv-toolchain-convention document linked above. These instructions are only available for riscv64 at this time.
XSfvcpLLVM implements version 1.0.0 of the SiFive Vector Coprocessor Interface (VCIX) Software Specification by SiFive. All instructions are prefixed with sf.vc. as described in the specification, and the riscv-toolchain-convention document linked above.
XCVbitmanipLLVM implements version 1.0.0 of the CORE-V Bit Manipulation custom instructions specification by OpenHW Group. All instructions are prefixed with cv. as described in the specification.
XCVelwLLVM implements version 1.0.0 of the CORE-V Event load custom instructions specification by OpenHW Group. All instructions are prefixed with cv. as described in the specification. These instructions are only available for riscv32 at this time.
XCVmacLLVM implements version 1.0.0 of the CORE-V Multiply-Accumulate (MAC) custom instructions specification by OpenHW Group. All instructions are prefixed with cv.mac as described in the specification. These instructions are only available for riscv32 at this time.
XCVmemLLVM implements version 1.0.0 of the CORE-V Post-Increment load and stores custom instructions specification by OpenHW Group. All instructions are prefixed with cv. as described in the specification. These instructions are only available for riscv32 at this time.
XCValuLLVM implements version 1.0.0 of the Core-V ALU custom instructions specification by Core-V. All instructions are prefixed with cv. as described in the specification. These instructions are only available for riscv32 at this time.
XCVsimdLLVM implements version 1.0.0 of the CORE-V SIMD custom instructions specification by OpenHW Group. All instructions are prefixed with cv. as described in the specification.
XCVbiLLVM implements version 1.0.0 of the CORE-V immediate branching custom instructions specification by OpenHW Group. All instructions are prefixed with cv. as described in the specification. These instructions are only available for riscv32 at this time.
Experimental C Intrinsics¶
In some cases an extension is non-experimental but the C intrinsics for that extension are still experimental. To use C intrinsics for such an extension from clang, you must add -menable-experimental-extensions to the command line. This currently applies to the following extensions:
ZvbbZvbcZvkbZvkgZvknZvkncZvknedZvkngZvknhaZvknhbZvksZvkscZvksedZvksgZvkshZvkt
