Repository navigation
Tracking Issue for RISC-V Ratified Extensions Intrinsics #114544
Description
This issue tracks the implementation of all the intrinsics linked to the Ratified RISC-V Extensions. The, not yet stable intrinsics are behind the riscv_ext_intrinsics nightly feature.
Steps
- Implement all extensions in
stdarch- Cryptography Extensions Volume I: Scalar & Entropy Source Instructions
-
Zkr. Entropy source extension - Bit-Manipulation
- Zicntr and Zihpm
- Zicsr
-
Half-Precision -
Float in Integer - Vector Extension
- Adjust module level documentation
- Stabilization PR
Unresolved Questions
-
How to deal with instructions that are already dealt with by LLVM intrinsics and library features (e.g.cpopandu*::count_ones)? Include them or not? - Use
usizefor riscv32 orriscv64specific intrinsics or useu32andu64respectively?- We'd like to split them, matching the C API Tracking Issue for RISC-V Ratified Extensions Intrinsics #114544 (comment)
-
How to deal with intrinsics involving immediate values?Use theasm_constfeature outlined in Tracking Issue for asm_const #93332.Use the trick described in Implement all x86 vendor intrinsics stdarch#40 and illustrated in_mm_cmpestri.
- All intrinsics have fuzz tests against the C version before stabilization
- How to deal with CSR registers?
- Can we source titles and descriptions from the specifications? License issues?
- Dealing with the Vector extension is very difficult due to dynamically sized registers (RFC: Add a scalable representation to allow support for scalable vectors rfcs#3268).
Implementation History
- Implement RISC-V Zk intrinsics stdarch#1453. Implements the Zk extension, except Entropy Source and Zkt.
- Implement RISC-V Zb intrinsics stdarch#1461. Implements the Zb extension.
- Stabilize Ratified RISC-V Target Features #116485. Stabilizes several RISC-V target features.
Reacted by Till Ulen, José Luis Cruz and Nazar Mokrynskyi
Activity
Add the `riscv_ext_intrinsics` feature for rust-lang#114544
coastalwhite commentedon Aug 25, 2023
Two additional points:
rustc_legacy_const_genericsfor immediate values instead.coastalwhite commentedon Sep 1, 2023
Entropy Source of the Cryptographic Scalar Extension are not implemented in LLVM. Therefore, it should be implemented with inline assembly and is not part of the implemented intrinsics.
coastalwhite commentedon Sep 1, 2023
Extensions such as
Zfinx,ZdinxandZhinxare all done by LLVM without intrinsics and therefore don't have to be done.Auto merge of rust-lang#116485 - coastalwhite:stabilize-riscv-target-…
main: Enable riscv_ext_intrinsics feature
Rollup merge of rust-lang#138823 - a4lg:riscv-feature-addition-base-i…
Unrolled build for rust-lang#138823
7 remaining items
nia-e commentedon Sep 22, 2026
The team discussed this in today's meeting and a variety of opinions were expressed, but the overall conclusion is that we'd like to hear from ecosystem users / risc-v people as to which is preferable. Either option is fine, but this kind of conversation is of course very prone to bikeshedding ^^
TechnoPorg commentedon Sep 23, 2026
Although this isn't a very weighty take, I figured I'd chime in to say that my work project uses the RV32 bit manipulation and crypto extensions (currently via inline assembly since we're on stable) and it's more ergonomic for us to work with u32 than usize.
tgross35 commentedon Oct 11, 2026
@topperc pointed out at rust-lang/stdarch#2247 (comment) that in C the 32- and 64-bit version of these intrinsics are separate and you can use both on riscv64. This seems worth following since applications that can use the 32-bit versions don't need to do anything special to work with both rv32 and rv64. @rust-lang/libs @newpavlov and others on this thread, any thoughts?
More concretely, I think we should copy the table at https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/src/c-api.adoc#scalar-bit-manipulation-extension-intrinsics but drop the
__riscv_prefix as we have been. E.g. our existingclmulh(usize, usize) -> usize, available on both rv32 and rv64, will be split intoclmulh_32(u32, u32) -> u32available on both andclmulh_64(u64, u64) -> u64which is 64-bit only.Re-nominating since this could use a bit of consensus.
@rustbot label +I-libs-nominated
Also did a quick check that the 32-bit intrinsics are still single instructions on 64-bit https://clang.godbolt.org/z/hYYYPvG6s.
newpavlov commentedon Oct 11, 2026
IIUC RV64 does not have a separate 32-bit clmul instruction (spec), so on the first glance I don't think we should add a separate intrinsic for it.
tgross35 commentedon Oct 11, 2026
That one is marked "Emulated with clmul+sext.w on RV64" in the table. I think it's fine to exclude those.
TechnoPorg commentedon Oct 12, 2026
@newpavlov In rust-lang/stdarch#1453 and rust-lang/stdarch#1461 part of the review was saying not to implement those extra intrinsics and to let LLVM handle it. Would you still want to have them?
On that note @tgross35, of the bit manipulation intrinsics we currently implement (xperm*, clmul*, orc_b, {un}zip), the 32-bit versions are all either RV32-only or emulated with multiple intrinsics, so there would only be shared intrinsics if we add the extra ones mentioned above.
newpavlov commentedon Oct 12, 2026
In the case of order swapping intrinsics it may be useful to have them to be sure that code uses dedicated hardware instructions instead of relying on software emulation. In other words, explicitly using
rev8would force us to enable the required target feature, while withswap_bytesit could be easily forgotten. It also would be consistent with the aforementioned x86 intrinsic.I am not sure it's worth to add intrinsics for all instructions (especially those from the Zba extension), but to be on the safe side I would do it nevertheless without doing any value judgment. But it's not a strong opinion, so I am fine with skipping some instructions. They could be added later if there is a demand for them.
cc @Amanieu
topperc commentedon Oct 12, 2026
llvm can drop that sext.w in many cases. For example, if the result of the clmul is stored to a 32-bit location, there won't be a redundant a sext.w.
nia-e commentedon Oct 13, 2026
Per discussion in the libs meeting, let's stick to what the C spec says - so, separate
u32andu64. Thanks!Amanieu commentedon Oct 13, 2026
To be clear: the conclusion we reached in the meeting is also that we should be precisely matching the C API with the
__riscv_prefix removed, as @tgross35 suggested. This means having separate versions with_32and_64suffixes, which we judged was important because the operation of these intrinsics is dependent on the operand size.Verify and document RISC-V rv64 (scalar) support
tgross35 commentedon Oct 27, 2026
That all got updated so our names and signatures are consistent with C. There is a stabilization PR at rust-lang/stdarch#2248 covering the batmanip and crypto tables at https://github.com/riscv-non-isa/riscv-c-api-doc/blob/b3df26527b2fa27d7219b6d6abe775f6bd13615b/src/c-api.adoc, I'm planning to propose FCP once rust-lang/stdarch#2254 merges so feel free to take a look.