On Sun, Jun 1, 2025 at 4:06 AM Robin Dapp <rdapp....@gmail.com> wrote: > > I stumped across this change from > > https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/88 > > and I want to express my strong disagreement with this change. > > > > > > 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. > > There are two reasons for the change: > > - Adhere to the usual "last option wins" convention and at the same time
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. > - Make it easy to specify an overriding -march string representing a CPU > without spelling out the >200 char expanded arch string, a very error-prone > procedure. > > I agree that fixing the "project build system" might be another way of having > only a single -march in a compiler command line but it doesn't match my > experience. Over the years I have seen a significant number of projects where > multiple -marchs where present. With the "last option wins" convention this > works and a user always has a "last ditch" way of setting their preferred > architecture. > A typical use case is a default march that is overridden by CFLAGS. There's > nothing to be fixed here because it's standard procedure. In that situation > we > would always need the full -march string and that can't be what we want? When multiple -march= options are specified, the last one wins. However, this does not apply when combining -march= and -mcpu=, as -march= is intended to restrict the feature set. If you'd like to propose that -mcpu= should override -march=, one approach could be introducing a special value for -march=, such as -march=unset. > What's your main concern? The less clear separation between arch and CPU? > I don't think the change takes anything away from -march but just adds a > shortcut "set the arch level to what this CPU supports". That's fully in line > with what other targets are doing, also on the clang side. * -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. > Ideally (IMHO) we'd also imply an -mtune when specifying -march by default > rather than using -mtune=rocket or so. 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 > If we had an -mcpu=... that overrode -march and -mtune we'd already have a > good > way of achieving what I intended. In that case -march wouldn't need to be > changed but to my understanding this has been unwanted so far. For me a "last > option wins" -mcpu that overrides march and mtune would also work and would > keep the clear separation between -march and -mtune.
