Stabilize 29 RISC-V target features (`riscv_ratified_v2`) by a4lg · Pull Request #145948 · rust-lang/rust (original) (raw)

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

This commit stabilizes RISC-V target features with following constraints:

Describes a ratified extension.
Implemented on Rust 1.88.0 or before.
Waiting for four+ version cycles seems sufficient.
Does not disrupt current rustc's target feature (cf. Need comprehensive story for target_feature compat #140570) + ABI (cf. Some -Ctarget-features must be restrained on RISCV #132618) handling.
It excludes E and all floating point-arithmetic extensions. The Zfinx family does not involve floating point registers but not stabilizing for now to avoid possible confusion between the F extension family.
Not vector-related (floating point and integer).
While integer vector subsets should not cause any ABI issues (as they don't use ABI-dependent floating point registers), we need to discuss before stabilizing them.
Supported by the lowest LLVM version supported by rustc (LLVM 20).

List of target features to be stabilized:

b
za64rs (no-RT)
za128rs (no-RT)
zaamo
zabha
zacas
zalrsc
zama16b (no-RT)
zawrs
zca
zcb
zcmop
zic64b (no-RT)
zicbom
zicbop (no-RT)
zicboz
ziccamoa (no-RT)
ziccif (no-RT)
zicclsm (no-RT)
ziccrse (no-RT)
zicntr
zicond
zicsr
zifencei
zihintntl
zihintpause
zihpm
zimop
ztso

Of which, 20 of them (29 minus 9 "no-RT" target features) support runtime detection through std::arch::is_riscv_feature_detected!().

Corresponding PR for the Reference: rust-lang/reference#1987

Description in older revision(s)

Not vector-related (including not FP-related ones).
No ABI issues will not occur unless floating point registers are involved. But for integer-only vector ones, we'll be stabilizing in another time.

The original text is rewritten to avoid confusion as per @RalfJung's request.

Of which, 19 of them support runtime detection through std_detect.

This is rewritten to correlate this PR with a public API (instead of an internal crate).

r? @Amanieu
@rustbot label +O-riscv

rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.

labels

Aug 28, 2025

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

I expect that this PR lands on the version 1.92 cycle (I chose extensions with relatively low risk factors) but happy if it could be merged in the version 1.91 cycle.

Amanieu added T-lang

Relevant to the language team

I-libs-api-nominated

Nominated for discussion during a libs-api team meeting.

T-libs-api

Relevant to the library API team, which will review and decide on the PR/issue.

and removed T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.

I-libs-api-nominated

Nominated for discussion during a libs-api team meeting.

labels

Aug 29, 2025

LGTM, these are all officially ratified RISC-V extensions.

@rfcbot merge

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

We'll need a PR to the Reference submitted and accepted ahead of this being merged.

@rfcbot reviewed

cc @rust-lang/lang-docs @RalfJung

Consideration: Feature Naming (for `std_detect`)

The only initial intent of riscv_ratified_v2 (which feels a bit blunt) was to avoid crashing with existing riscv_ratified1 and later noticed that x86 uses various feature names on stabilization.

I considered the similar after the initial submission but didn't for several reasons:

Many extensions to be stabilized are general purpose (even some of them are split from an early version of the I base ISA) and clear distinction will confuse the users between plain riscv_ratified (it's just a collection of extensions where runtime detection of them is stabilized in Rust 1.78.0 and contains rich extensions like scalar cryptography).
Considering future extensions to be stabilized in Rust and the history (some RISC-V extensions are split from others and semantic naming may not work in the near future), either of them seems inevitable:
1. Using the extension name itself or similar or
2. Using blunt version schemes like in this PR.

After consideration, I prefer blunt naming scheme (pure versioning regardless of the category) for runtime detection of RISC-V extensions.

Consideration: Deferring to Version 1.92 Cycle may Have its Benefit

Although I'll rush for the version 1.91 cycle if possible, I have to say that deferring this might be an option.

I'm talking about #145071, which raises the minimum LLVM version to 20. After this PR is merged, I think we can safely introduce the Zacas extension without riscv_ratified_v3 (I excluded Zacas from this PR because of this minimum LLVM version issue).

So, if we don't make it to the version 1.91 cycle, waiting for #145071 might be an option.

Footnotes

The same feature name does not allow multiple stabilized versions. ↩

a4lg added a commit to a4lg/rust-reference that referenced this pull request

Aug 30, 2025

The Zb extension does not exist and we instead have the B extension which is a superset of the three subextensions: Zba, Zbb and Zbs.

This commit fixes this issue and updates the reference URL to the source code of the latest ratified ISA Manual (version 20250508).

To align with rust-lang/rust#145948, this commit performs rename, not removal.

a4lg added a commit to a4lg/rust-reference that referenced this pull request

Aug 30, 2025

a4lg mentioned this pull request

Aug 30, 2025

a4lg added a commit to a4lg/rust-reference that referenced this pull request

Aug 30, 2025

The Zb extension does not exist and we instead have the B extension which is a superset of the three subextensions: Zba, Zbb and Zbs.

This commit fixes this issue and updates the reference URL to the source code of the latest ratified ISA Manual (version 20250508).

To align with rust-lang/rust#145948, this commit performs rename, not removal.

a4lg added a commit to a4lg/rust-reference that referenced this pull request

Aug 30, 2025

a4lg added a commit to a4lg/rust-reference that referenced this pull request

Aug 30, 2025

The Zb extension does not exist and we instead have the B extension which is a superset of the three subextensions: Zba, Zbb and Zbs.

This commit fixes this issue and updates the reference URL to the source code of the latest ratified ISA Manual (version 20250508).

To align with rust-lang/rust#145948, this commit performs rename, not removal.

a4lg added a commit to a4lg/rust-reference that referenced this pull request

Aug 30, 2025

No ABI issues will not occur unless floating point registers are involved. But for integer-only vector ones, we'll be stabilizing in another time.

I can't parse this comment, too many negations.^^ Integer vector registers can also cause ABI issues, if they are sometimes used by the calling convention but not always available.

I can't parse this comment, too many negations.

Double negation in the first sentence is intended. Still, there are too much negations after that, I have to admit. I'll try if I can improve this.

Integer vector registers can also cause ABI issues, if they are sometimes used by the calling convention but not always available.

Did I miss something?

In the standard ABI and normal cases, all vector registers are function-local temporaries.
If variant calling convention is used in a function, standard ABI defines how to communicate between the function itself (callee) and the caller using vector registers but nothing more (and all preserved vector registers are callee-saved). I can't find a case where vector integer ops can cause ABI issues.

Double negation in the first sentence is intended

Please avoid that, it makes things very hard to read and very easy to misunderstand.

"No ABI issues will not occur" means that ABI issues will occur which I hope is not what you meant.

If variant calling convention is used in a function, standard ABI defines how to communicate between the function itself (callee) and the caller using vector registers but nothing more (and all preserved vector registers are callee-saved). I can't find a case where vector integer ops can cause ABI issues.

I don't know what the "variant calling convention" is. I also don't know the specifics of any of these extensions, or really much about RISC-V at all. I am just replying to a comment that seemed to somehow say that "float registers could cause a problem but integers cannot", which doesn't make sense to me. Any extensions that makes more registers available could become a problem if arguments start to be passed in those registers. If there are no new registers (nor other new machine state) or the registers are never used for arguments, then great, we have no problem.

The comment seems to say that something with integer vectors should be stabilized "another time", so I hope we are fine. But I am not sure since I have a hard time parsing that sentence. It first talks about floats and then about ints, but ints happen another time -- so are floats affected now in this PR or not?

Sorry for being so nitpicky here, but I'd rather not risk introducing some soundness issue over a misunderstanding caused by a language barrier. Better to double-check. :)

Please avoid that, it makes things very hard to read and very easy to misunderstand.

Understood. I think I need to rewrite the entire paragraph.

I am just replying to a comment that seemed to somehow say that "float registers could cause a problem but integers cannot", which doesn't make sense to me.

The reason behind "floating point registers cause an ABI issue" is something like #[target_feature(enable = "f")] can change how to pass floating point numbers.

However, passing something through vector registers require the callee to enable variant calling conventions (e.g. vector intrinsics in future core::arch would enable variant calling convention) and we can only pass vector data (unavailable on non-vector environment).
On all other cases, vector registers are never used to pass information between functions.

This comment has been minimized.

Rebased and made minor adjustments to the commit message (no changes in the code).

@RalfJung I think this is at least better than before.

Not vector-related (floating point and integer).
While integer vector subsets should not cause any ABI issues (as they don't use ABI-dependent floating point registers), we need to discuss before stabilizing them.

EDIT: Minor correction is made after initial correction.

Sorry for being so nitpicky here, but I'd rather not risk introducing some soundness issue over a misunderstanding caused by a language barrier. Better to double-check. :)

I completely agree that. We'd better to discuss it.

Thanks! I'm still confused about what's happening with integer vectors, but since they are not being stabilized here we don't have to resolve that now.

a4lg added a commit to a4lg/rust-reference that referenced this pull request

Sep 17, 2025

This commit stabilizes RISC-V target features with following constraints:

Describes a ratified extension.
Implemented on Rust 1.88.0 or before. Waiting for four+ version cycles seems sufficient.
Does not disrupt current rustc's target feature + ABI handling. It excludes "E" and all floating point-arithmetic extensions. "Zfinx" family does not involve floating point registers but not stabilizing for now to avoid possible confusion between the "F" extension family.
Not vector-related (floating point and integer). While integer vector subsets should not cause any ABI issues (as they don't use ABI-dependent floating point registers), we need to discuss before stabilizing them.
Supported by the lowest LLVM version supported by rustc (LLVM 20).

List of target features to be stabilized:

"b"
"za64rs" (no-RT)
"za128rs" (no-RT)
"zaamo"
"zabha"
"zacas"
"zalrsc"
"zama16b" (no-RT)
"zawrs"
"zca"
"zcb"
"zcmop"
"zic64b" (no-RT)
"zicbom"
"zicbop" (no-RT)
"zicboz"
"ziccamoa" (no-RT)
"ziccif" (no-RT)
"zicclsm" (no-RT)
"ziccrse" (no-RT)
"zicntr"
"zicond"
"zicsr"
"zifencei"
"zihintntl"
"zihintpause"
"zihpm"
"zimop"
"ztso"

Of which, 20 of them (29 minus 9 "no-RT" target features) support runtime detection through std::arch::is_riscv_feature_detected!().

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

a4lg changed the title~~Stabilize 28 RISC-V target features (riscv_ratified_v2)~~ Stabilize 29 RISC-V target features (riscv_ratified_v2)

Sep 17, 2025

Update: since minimum LLVM version is raised to 20, the Zacas extension (zacas target feature) is added to this PR.

a4lg added a commit to a4lg/rust-reference that referenced this pull request

Sep 18, 2025

a4lg added a commit to a4lg/rust-reference that referenced this pull request

Sep 29, 2025

a4lg added a commit to a4lg/rust-reference that referenced this pull request

Sep 29, 2025

This commit directly corresponds to rust-lang/rust#145948. See that proposal for criteria of 29 new extensions.

Notes (for the Rust reference):

Updated existing a and c to imply its subset(s).
- a equals zalrsc and zaamo combined (imply both from a).
- The C extension always implies the Zca extension and conditionally implies Zcf and/or Zcd extensions (on RISC-V) but c (Rust target feature) only implies zca as both zcf and zcd are not to be stabilized on this proposal.
For each extension, linked to the first document containing it with the ratified state. For instance, all extensions present in the RVA23 profiles link to (3) (despite that they are present in (2)) because they were not ratified at the time when (2) is published.

References:

RISC-V Instruction Set Manual (version 20250508): <https://github.com/riscv/riscv-isa-manual/tree/20250508>
RISC-V Profiles (version 1.0 - RVA23 is not stabilized at the time): <https://github.com/riscv/riscv-profiles/tree/v1.0>
RISC-V Profiles (RVA23/RVB23-ratified version): <https://github.com/riscv/riscv-profiles/tree/rva23-rvb23-ratified>

a4lg added a commit to a4lg/rust-reference that referenced this pull request

Sep 29, 2025

This commit directly corresponds to rust-lang/rust#145948. See that proposal for criteria of 29 new extensions.

Notes (for the Rust reference):

Updated existing a and c to imply its subset(s).
- a equals zalrsc and zaamo combined (imply both from a).
- The C extension always implies the Zca extension and conditionally implies Zcf and/or Zcd extensions (on RISC-V) but c (Rust target feature) only implies zca as both zcf and zcd are not to be stabilized on this proposal.
For each extension, linked to the first document containing it with the ratified state. For instance, all extensions present in the RVA23 profiles link to (3) (despite that they are present in (2)) because they were not ratified at the time when (2) is published.