On Mon, 02 Jun 2025 12:35:45 PDT (-0700), Robin Dapp wrote:
I don't quite follow this part. IIUC the rules before this patch were
-march=ISA: Generate code that requires the given ISA, without
changing the tuning model.
-mcpu=CPU: Generate code for the given CPU, targeting all the
extensions that CPU supports and using the best known tuning model
for that CPU.
-mtune=CPU: Use the tuning model for a CPU, but don't change the
and the rules after this patch are
-march=ISA/CPU: Generate code that requires the given ISA or the ISA
implemented by the given CPU, without changing the tuning model.
-mcpu=CPU: Generate code for the given CPU, targeting all the
extensions that CPU supports and using the best known tuning model
for that CPU.
-mtune=CPU: Use the tuning model for a CPU, but don't change the
which isn't really all that different -- we're just adding a shorthand
for and ISA that maches the CPU names we use elsewhere. IMO that's
perfectly reasonabel, given that ISA strings in RISC-V are insane now.
Unless I'm missing something this basically matches the Arm behavior and
we're not currently doing the x86-like thing where -march changes the
default tuning model. I don't have a strong opinion here: IIUC x86 and
Arm do different things here so we're going to break someone's
assumptions either way.
Yea, but I can understand that it might be slightly more complex now than
before.
We're able to use a CPU name in an option that could not take one before. On
top, this CPU name can now override previous options when it couldn't before.
Of course overriding is a property of the option and not the option value but
there is a way of getting a tad more confused than before. Manageable IMHO.
Ya, but I think the behavior is the same: -march overrides -mcpu, for
any values in -march. So it's really still just shorthand.
Unless I'm missing something?
The whole point of the patch was not having to use the full ISA string so if
there's consensus on that being a problem we need to make a change one way or
another.
Fangrui's mentioned unset which is the aarch64 way of solving it. If you want
to override an earlier march you need to use -march=unset -mcpu=... so the full
string would e.g. be -march=rv64gc -march=unset -mcpu=whatever. I don't like
that option but it is a valid way to solve the "long ISA string" issue. Same
for -mtune.
That really sounds like an orthogonal feature, though. I agree it
smells kind of weird, but if Arm does it I wouldn't be opposed.
And yeah, -march implying -mtune is a different matter still and we have
already seen that there are fundamentally opposite opinions on that one as well
;)
Yes, though by merging this patch to make -march take a CPU string we've
taken a side there -- there's not really a way to have a tuning for an
ISA string, so there's no grey area.
So maybe we should have something like
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8de00854a05..318ab507bed 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -31191,6 +31191,12 @@ When the RISC-V specifications define an extension as
depending on other
extensions, GCC will implicitly add the dependent extensions to the enabled
extension set if they weren't added explicitly.
+Note that @option{-march} does not change the tuning behavior, even when a CPU
+name is provided. Users that want to change both the target ISA and the tuning
+should either specify both @option{-march} and @option{-mtune}, or use
+@option{-mcpu} (which does not override previous values for @option{-march} or
+@option{-mtune}).
+
@opindex mcpu
@item -mcpu=@var{processor-string}
Use architecture of and optimize the output for the given processor, specified
to describe the behavior somewhere users are more likely to run into it?
Not sure that'll actually do anything, but at least we'll have a way to
point the bugs that Intel-assuming users file to complain about the
Arm-like behavior...
--
Regards
Robin
