On Sun, 01 Jun 2025 22:18:21 PDT (-0700), Robin Dapp wrote:
This rule clearly applies to directly related options like -ffoo and
-fno-foo, but it’s less obvious for unrelated pairs like -ffoo and
-fbar especially when there is traditionally strong specifics.
In many cases, the principle of "the most specific option wins"
governs the behavior.
Here we have a case where -ffoo and -fbar overlap so they are not unrelated.
If the most specific option wins then -mcpu should win as it specifies more
than either -mtune or -march individually.
I'd argue that "most specific wins" means that -march/-mtune beat -mcpu,
which is the behavior we have now. I actually don't like that behavior,
but if that's the general rule then I think we're actually doing the
right thing there?
Either way I don't think we can change it, as it's documented behavior
and changing it would break users' build scripts.
* -march= and -mcpu= has become less orthogonal, requiring users to
navigate more complex rules.
* We've lost the ability to use combinations like -march=LOWER
-mcpu=HIGHER or -mcpu=HIGHER -march=LOWER to disable specific target
features or detect incompatibilities.
* We landed the commit 4a182418c89666e7594bcb0e5edc5194aa147910
hastily on May 23, 2025, with far-reaching implications that weren't
fully considered.
Sorry if I'ma bit lost here, 4a182418c89 ("RISC-V: Support CPUs in
-march.") is the patch in this thread?
I can buy into the first point to some degree but IMHO it's not much more
complicated.
I'd argue we actually haven't implemented any more non-orthoganality in
the rules here. The core of the issue for me is how -march/-mtune and
-mcpu interact WRT overriding each other, not the contents of the
string we can stick in each option.
If anything this makes it easier for me to understand, as I can stick
the same string in any of the options.
The second point I'm not so sure about. Why have we lost anything? All we now
can do is use a shorthand CPU name instead of a lengthy arch string and
-march=lower -mcpu=higher is still available, as well as the other way around.
Yes, I think we didn't lose anything here. Unless I'm misunderstanding
something the march/mtune/mcpu mixing rules didn't change, just the way
we can spell values for -march (where we can now provide a CPU name as
shorthand that means "all the extensions that CPU supports").
And the third point is IMHO exaggerated. We're at the beginning of stage 1
when more experimental things hit the trunk that can easily be adjusted. So
neither is anything done hastily nor do I believe the implications are that far
reaching.
You could just have said something like: "Is this set in stone already? In
order to achieve what you want we could also introduce an -march=unset and
-mtune=unset instead".
Yes, IIUC we could revert this (or change it or whatever) as it's not
released -- not suggesting we do that right now, just that we can.
(and throwing in my standard blurb about that toolchain conventions repo
at the RISC-V fonudation having all sorts of issue WRT compatibility and
matching implementations, so it's not really worth looking into...)
IMHO there is enough difference in aarch64's and riscv's extension model that
it warrants doing some things not in their exact same way. aarch64's arch
strings don't regularly exceed a line.
I strongly disagree with implicitly setting -mtune= when specifying
-march=. Adding more semantics to -march complicates the rules users
must follow and increases the risk of error-prone patterns.
The traditional behavior established by aarch64, in contrast, is easy
to remember:
-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
x86's scheme is also easy to remember:
-march=arch or cpu including its proper tune model
-mtune=different tune model
I don't have a problem changing something or reverting if there's consensus but
so far ITSM that it's mostly a matter of personal taste. If people prefer
-march=unset etc. (I don't) then let's go for that? We need a bit more input
for that, though. So far we just have one vote each.
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.
--
Regards
Robin
