Document Architecture Profile Test Macros

[ZhongyaoChen]

Add documentation for RISC-V profile test macros that enable compile-time profile detection (e.g., __riscv_rva23u64).

This aligns with the GCC patch that implements RISC-V profile macro support in the compiler.

[cmuellner]

The word "match" leaves some room for interpretation:

• Are the S* and H* extensions of a profile considered in the match?
• What if additional extensions beyond those in the profile are enabled?
• What if vendor extensions are enabled?

[ZhongyaoChen]

Are the S* and H* extensions of a profile considered in the match?

Yes, if they are part of the profile definition.

What if additional extensions beyond those in the profile are enabled?

Additional extensions do not prevent a profile match. as long as all extensions required by the profile are present, this matched profile macro will be defined.

What if vendor extensions are enabled?

don't affect profile matching.

[cmuellner]

Thanks for the PR!

I guess the use case for this is to test for profiles instead of several individual extensions at compile time.

Do you know if these macros exist in LLVM?

[ZhongyaoChen]

I guess the use case for this is to test for profiles instead of several individual extensions at compile time.

Exactly! That's precisely the intention.

Do you know if these macros exist in LLVM?

AFAIK, they don't exist in LLVM yet. However, I have prepared a patch for LLVM as well and plan to submit it later.

[topperc]

Doesn't this create a compatibility issue.

Developer writes code for RVA23U64 today.
In the future the code is compiled with RVA30U64 that is superset of RVA23U64. __riscv_rva23u64 macro is not defined because __riscv_rva30u64. Code no longer does the correct thing and must be updated to check for __riscv_rva30u64 OR __riscv_rva23u64.

[ZhongyaoChen]

Thanks for the review, I do miss the compatibility issue.
maybe this better ? anyway, need reconsider the macro definitions.

#define __riscv_profile_number 23
#define __riscv_profile_class 'A'
#define __riscv_xlen 64

[kito-cheng]

#define __riscv_profile_class 'A'

https://github.com/riscv/riscv-profiles/blob/main/src/profiles.adoc#34-profile-naming-convention

Single letter might not work because spec say:

"A specific profile family name string. Initially a single letter (I, M, or A), but later profiles may have longer family name strings."

Also rvX30u64 might also a super-set of rva23u64...so I would prefer to define every profile macro if the extension meet the requirement of that profile.

That means -march=rva23s64 will define __riscv_rva23s64, __riscv_rva23u64, __riscv_rvi20u64, __riscv_rva20u64, __riscv_rva20s64, __riscv_rva22u64 and __riscv_rva22s64.

This seems little bit mess, but that could guarantee the code guarded with __riscv_rva23u64 could work on any future version which compatible with that.

[topperc]

Do you have an example use case for this? I wouldn't expect one piece of code to be dependent on everything in a profile. It's effectively listing a bunch of requirements that probably don't apply. This may make it hard to understand the true requirements in the future if the code needs to be updated for a new profile with fewer extensions.

We've already seen something similar with Zmmul and Zca. Code that used __riscv_m or __riscv_c but only needed multiply or integer compressed, may need to be updated to use __riscv_zmmul or __riscv_zca.

[ZhongyaoChen]

Do you have an example use case for this?

have no realworld example.

I wouldn't expect one piece of code to be dependent on everything in a profile.

Agree.

Hard to understand the true requirements in the future if the code needs to be updated for a new profile with fewer extensions.

You’re right, but some developers may prefer the profile macro for convenience. maybe leave the implementation up to them ?