Microarchitecture test macro proposal

[garthlei]

Some developers may want to use macros to guard their microarchitecture-specific optimized code. We note that other architectures like x86 have macros based on the -mtune option, and maybe we could do the same for RISC-V?

[lenary]

My concern about this is it makes it easy to make code that only works for one microarch, and breaks if compiled with a different -mtune, which I think we'd prefer to avoid.

Currently how -mtune works is a little up in the air (see riscv-non-isa/riscv-toolchain-conventions#122 ), maybe once we know what exactly is happening there (including with the additional tuning options), we can come back to this?

[garthlei]

Hi @lenary, thank you for your reply!

My concern about this is it makes it easy to make code that only works for one microarch, and breaks if compiled with a different -mtune, which I think we'd prefer to avoid.

Do you mean something like the scenario where the developer writes some microarch-specific code within some #ifdef block without an #else block and gets a compilation error, or the scenario where the developer writes some code that only works for one microarch (say, SiFive 7) within a #ifdef __riscv_sifive_7_series block, compiles it with -mtune=sifive-7-series, and expects it to work as well on other models?

Currently how -mtune works is a little up in the air (see riscv-non-isa/riscv-toolchain-conventions#122 ), maybe once we know what exactly is happening there (including with the additional tuning options), we can come back to this?

I do agree that the documentation of the macros needs rephrasing if the new -mtune syntax is accepted. Currently I suggest the test macros be used only for microarchitectures and cores (the tuning model part of the new -mtune syntax).

[lenary]

Do you mean something like the scenario where the developer writes some microarch-specific code within some #ifdef block without an #else block and gets a compilation error

I think I was thinking of this originally

or the scenario where the developer writes some code that only works for one microarch (say, SiFive 7) within a #ifdef __riscv_sifive_7_series block, compiles it with -mtune=sifive-7-series, and expects it to work as well on other models?

But this could also be a problem - it's not just "work as well on other models", the problem comes if you use __riscv_sifive_7_series to detect architecture features available on the 7 series.

@topperc thinks "clang stopped defining new tune macros for x86 years ago", so we should maybe try to learn the lessons other architectures have. I trust (but haven't verified) this claim, but this proposal should probably address what happened with x86 and why riscv won't hit the same issues.

[garthlei]

or the scenario where the developer writes some code that only works for one microarch (say, SiFive 7) within a #ifdef __riscv_sifive_7_series block, compiles it with -mtune=sifive-7-series, and expects it to work as well on other models?

But this could also be a problem - it's not just "work as well on other models", the problem comes if you use __riscv_sifive_7_series to detect architecture features available on the 7 series.

I can now imagine a scenario where someone writes some inline assembly assuming VLEN≥512 in a #ifdef __riscv_xyz_series block (where xyz_series supports Zvl512b). It may compile without zvl512b in the compiler option, but it will break under machines that do not support that. That can be a problem indeed.

@lenary Does it sound better to define only CPU macros, which rely on -mcpu options, instead of tune macros? We have to deal with the overriding rules of -mcpu, -march, and -mtune, though, to make sure there are only defined in limited cases, and how the macro should work with the new -mcpu syntax (riscv-non-isa/riscv-toolchain-conventions#139) is another issue.

[apazos]

Hello @garthlei, your proposal was discussed at the last Toolchain SIG meeting on 01/15:

• It is related to the mtune discussion. See #122 and [RISCV] Introduce a new tune feature string syntax and its parser llvm/llvm-project#168160.
• It is considered as a reasonable request.
• Decision to wait until mtune discussion is complete.

See meeting notes at https://riscv.atlassian.net/wiki/spaces/SSNJ/pages/1137115137/2026-01-15+Toolchain+SIG+Meeting+Notes