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.
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.
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
;)
--
Regards
Robin
