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.
* -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.
I can buy into the first point to some degree but IMHO it's not much more
complicated.
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.
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".
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.
--
Regards
Robin
