Extend the -march syntax to accept CPU name

[kito-cheng]

GCC community just got a patch[1] that accept CPU name for -march, the reason is -mcpu has lower priority even it appeared after -march, that means it's hard to specify a arch string via -mcpu in a build system, because sometime you don't know the whole CFLAGS/CXXFLAGS.

The only way to make sure to using arch string from -mcpu=xxx is expand that to -mcpu=xxx + -march=, however as we know the arch string is become terribly long.

So the idea is maybe we should just allow that on -march to prevent that.

The main decision point is: should we allow CPU name in -march=?

And few extra decision point is:

• Should we allow it append extensions with the same mechanism as profile.
• Should we allow it to subtract/remove extensions from a CPU?
• Should -march=<cpu> also implicitly set -mtune?

[1] https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684398.html

[kito-cheng]

One thought pop to my mind is...maybe we should just treat -mcpu as -mtune + -march then honor the order, I mean the rule of the last one win.

e.g.

Arch string of foo is rv64gcv

riscv64-elf-gcc -march=rv64gc -mcpu=foo will treat as riscv64-elf-gcc -march=rv64gc -march=rv64gcv -mtune=foo, then we will take rv64gcv since -mcpu=foo is appear after -march=rv64gc.

Rather than resolve as riscv64-elf-gcc -march=rv64gc -mtune=foo like current rule.

[pz9115]

Seems it already merged into gcc upstream

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4a182418c89666e7594bcb0e5edc5194aa147910

[MaskRay]

Perhaps I'm accustomed to Arm's behavior, but I believe using -march= to target a specific CPU isn't ideal.

• -march=X: (execution domain) Generate code that can use instructions available in the architecture X
• -mtune=X: (optimization domain) Optimize for the microarchitecture X, but does not change the ABI or make assumptions about available instructions
• -mcpu=X: Specify both -march= and -mtune= but can be overridden by the two options. The supported values are generally the same as -mtune=. The architecture name is inferred from X

For execution domain settings, -march=X overrides -mcpu=X regardless of their positions.

In cases like -march=LOWER -mcpu=HIGHER or -mcpu=HIGHER -march=LOWER, the -march= option can disable certain target features.

I strongly disagree with Clang adopting this behavior.
I'm not convinced by the GCC patch explanation.

Suppose we have a Makefile that specifies -march=rv64gc by default.

In the project specifies a lower feature set, then the compiler should respect it or the user should fix the project build system.

[kito-cheng]

Discussion thread in GCC mailing list: https://patchwork.sourceware.org/project/gcc/patch/DA1VTWOH9M2K.1DNK9TEDV9GA4@gmail.com/

[kito-cheng]

So far we have 3 major options (more proposal are welcome):

1. Accept -march=<cpu-name>. not changing -mtune
2. Accept -march=<cpu-name>. also implied -mtune
3. Accept -march=unset and -mtune=unset to let -mcpu be able to override both options.

Here is example when we want to override arch with a cpu name by different options:

1. $ riscv64-linux-gcc -march=rv64gc -march=foo-cpu
2. $ riscv64-linux-gcc -march=rv64gc -march=foo-cpu
3. $ riscv64-linux-gcc -march=rv64gc -march=unset -mcpu=foo-cpu

And when we also want to override mtune:

1. $ riscv64-linux-gcc -march=rv64gc -march=foo-cpu -mtune=foo-cpu
2. $ riscv64-linux-gcc -march=rv64gc -march=foo-cpu
3. $ riscv64-linux-gcc -march=rv64gc -march=unset -mtune=unset -mcpu=foo-cpu

The feedback I got so far is:
Kito Cheng (me): 3 > 1 >>>> 2 (was 1> 3 >>>>2 (*1))
Robin Dapp: 2,1, 3
Craig Topper: 3 > 1 >>>> 2
Fangrui Song (MaskRay): 3 > 1 >>>>> 2

More feedback are welcome.

---

*1: Craig convinced me to change the preference order: -march=unset (or -march=cpu) means you don't have to repeat the cpu name twice when using -march+-mtune.

• e.g. -march=unset -mcpu=sifive-p670 vs -march=sifive-p670 -mtune=sifive-p670

[cmuellner]

Suppose we have a Makefile that specifies -march=rv64gc by default.

Probably this can be fixed in the Makefile using the ?= operator.
E.g.:

MARCH?="rv64gc"

[...]

%.o: %.c
        $(CC) -march=$(MARCH) $(CFLAGS) -c $^ -o $@

This allows invoking make like this: MARCH=rv64gc_zba_zbb make.

In general, I prefer to reduce the override mechanisms to a necessary minimum.
Supporting less typing is ok for me, but a workaround for special environments seems unnecessary.

Also, I prefer consistency with such flags across different architectures.
As a user, it is annoying if each architecture solves the same problem in a slightly different way.

[apazos]

Compatibility between LLVM and GCC is very important.
We discussed at the RVI Toolchain SIG on 06/05 how it is possible to revert the GCC patch if GCC and LLVM community agree on a new different scheme.

[kito-cheng]

I guess it worth to cross post my reply[1] on the GCC mailing list here:

I was thinking that since GCC is still in the development stage, it
would be fine to accept the change now and adjust it later, because
the release processes for GCC and LLVM are quite different.

I've always preferred having a consistent user interface between the
GNU toolchain and LLVM in the RISC-V world, and I've tried to avoid
making interface changes too quickly before we reach consensus. But
yeah, I was definitely a bit too hasty this time.

That's why I opened an issue in riscv-toolchain-conventions - to
gather different opinions. Also, thanks for pointing out that ARM
already has the -march=unset option.

Anyway, I’ll be more careful with this kind of thing next time. I know
there have been quite a few command-line interface issues between the
GNU toolchain and LLVM communities in the past, and it's not uncommon
for the GNU side to add new options without broader discussion. I'm
really trying not to fall into "GNUism". :P

[1] https://patchwork.sourceware.org/project/gcc/patch/DA1VTWOH9M2K.1DNK9TEDV9GA4@gmail.com/#203124

[wangpc-pp]

We also have some similar discussions here: llvm/llvm-project#144022 (comment).

[topperc]

I've posted a patch to LLVM to implement -march=unset. llvm/llvm-project#148321 I won't merge until we have consensus here.

[apazos]

@kito-cheng, Craig's LLVM patch and your GCC patch were merged, the documentation got updated #98. Can we close this issue?

[kito-cheng]

Resolved via #98 :)