Skip to content

Document Architecture Profile Test Macros#128

Open
ZhongyaoChen wants to merge 4 commits intoriscv-non-isa:mainfrom
ZhongyaoChen:add-profile-macros
Open

Document Architecture Profile Test Macros#128
ZhongyaoChen wants to merge 4 commits intoriscv-non-isa:mainfrom
ZhongyaoChen:add-profile-macros

Conversation

@ZhongyaoChen
Copy link
Copy Markdown

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.

Add documentation for RISC-V profile test macros that enable
compile-time profile detection (e.g., __riscv_rva23u64).
src/c-api.adoc Outdated
- The test macro for the RVA23U64 profile is `+__riscv_rva23u64+`.
- The test macro for the RVI20U32 profile is `+__riscv_rvi20u32+`.

The profile macro is defined (with value 1) when the compiler detects that the enabled extensions match a specific RISC-V profile.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Author

@ZhongyaoChen ZhongyaoChen Oct 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Collaborator

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
Copy link
Copy Markdown
Author

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
Copy link
Copy Markdown
Contributor

topperc commented Oct 14, 2025

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
Copy link
Copy Markdown
Author

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 ?

Define that compilers should set all compatible profile macros,
including lower privilege modes and previous versions, to ensure
forward compatibility.

1. The exact profile macro for the targeted profile
2. Lower privilege mode variants (e.g., when targeting an S-mode profile, the corresponding U-mode profile macro is also defined, since S-mode is a superset of U-mode)
3. All previous compatible profile versions
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this include profiles that are compatible but not from the same profile family. Like RVI20 is subset of all defined RVA profiles.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR adds comprehensive documentation for RISC-V architecture profile test macros, which enable compile-time profile detection through preprocessor macros like __riscv_rva23u64. This aligns with the GCC implementation that provides these macros for conditional compilation based on target profiles.

Key changes:

  • Introduces a new "Architecture Profile Test Macros" section explaining the naming conventions and usage patterns for profile detection macros
  • Documents the compatibility behavior where targeting a profile automatically defines macros for compatible lower privilege modes and previous profile versions
  • Provides concrete examples showing how -march=rva23s64 defines multiple compatible profile macros

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

- `+__riscv_rva22s64+`
- `+__riscv_rva22u64+`
- `+__riscv_rva20s64+`
- `+__riscv_rva20u64+`
Copy link
Copy Markdown
Contributor

@topperc topperc Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So __rvi20u64 should be listed here?

Is rvb23s64/u64 also a subset of rva23s64?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, __rvi20u64 should be there. Haven't checked rvb23, but I should add an ellipsis to show any profile with a subset of extensions should define its macro too.

Add __riscv_arch_test dependency note and subset example.
Show that profile macros are defined with value 1.
Copy link
Copy Markdown
Collaborator

@kito-cheng kito-cheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@lenary
Copy link
Copy Markdown
Contributor

lenary commented Nov 26, 2025

I'm still concerned these will be used where more specific extension test macros would also apply, which might be better from a portability perspective.

Do we have examples where these would guard sequences where either:

  • the assembly sequence is long and specific and would use several individual extension test macros in a complex way
  • the sequence relies upon a large enough combination of extensions that checking for each extension is unmaintainable (this threshold is, IMO, more than 3 extensions)

ZhongyaoChen added a commit to ZhongyaoChen/gcc that referenced this pull request Nov 26, 2025
This reverts commit 79b8f23.

Revert temporarily due to compatibility issues discussed in:
riscv-non-isa/riscv-c-api-doc#128

We will wait for this Pull Request to reach consensus and be merged before resubmitting a new patch.

gcc/ChangeLog:

	* common/config/riscv/riscv-common.cc (riscv_subset_list::get_profile_name):
	Revert.
	* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Revert.
	* config/riscv/riscv-subset.h (riscv_subset_list::get_profile_name): Revert.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/predef-profiles-1.c: Remove.
	* gcc.target/riscv/predef-profiles-2.c: Remove.
	* gcc.target/riscv/predef-profiles-3.c: Remove.
	* gcc.target/riscv/predef-profiles-4.c: Remove.
	* gcc.target/riscv/predef-profiles-5.c: Remove.
	* gcc.target/riscv/predef-profiles-6.c: Remove.
	* gcc.target/riscv/predef-profiles-7.c: Remove.
	* gcc.target/riscv/predef-profiles-8.c: Remove.

Signed-off-by: Zhongyao Chen <chen.zhongyao@zte.com.cn>
@ZhongyaoChen
Copy link
Copy Markdown
Author

ZhongyaoChen commented Nov 26, 2025

I don't have a specific code example at hand, but this request originates from developers in my company porting and optimizing code for the RVA23 platform. Not all of them are RISC-V experts, and they believe a profile macro would lower the burden compared to manually checking extensions, though they haven't started using it yet.

@ZhongyaoChen
Copy link
Copy Markdown
Author

I understand the concerns. From a portability perspective, specific extension macros are better.
The profile macro here just try to provide an additional option.
@kito-cheng Given that this PR has been a while, how should we move forward, just drop it or what ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants