On 17/02/2020 15:42, Richard Sandiford wrote:
"Richard Earnshaw (lists)" <richard.earns...@arm.com> writes:
On 14/02/2020 10:41, Andrew Pinski wrote:
On Fri, Feb 14, 2020 at 2:12 AM Richard Earnshaw (lists)
<richard.earns...@arm.com> wrote:
On 14/02/2020 03:18, apin...@marvell.com wrote:
From: Andrew Pinski <apin...@marvell.com>
Right if someone supplies a -mcpu= option and then overrides
that option with -march=*, we get a warning when they conflict.
What we need is a generic cpu for each arch level but that is not
that useful because the only difference would be the arch level.
The best option is to allow -mcpu=generic -march=armv8.5-a not to
warn and that is now a generic armv8.5-a arch.
Then they should use -mtune=generic, rather than -mcpu.
Does it make sense to run:
"make check RUNTESTFLAGS="--target_board=unix/{,-mcpu=octeontx2}"
to make sure there are no latent bugs floating around with slightly
different tuning/scheduling?
The majority of the aarch64.exp failures are due to that warning.
If not how would suggest to test a -mcpu= option?
There is another use case:
A specific object file is to be run only on armv8.5-a processors but
someone sets CFLAGS to include -mcpu=octeontx2.
How would you suggest going about handling this case?
These are the two major cases where having a -mcpu=generic which
overrides a previous -mcpu= option and still able to select a higher
-march= option.
-mcpu=generic should behave *exactly* the same way as specifying the CPU
you have, so to take an example, if your cpu is a Cortex-A72, then
-mcpu=generic and -mcpu=cortex-a72 should result in exactly the same
compiler output and diagnostics should be generated as if you'd
specified the latter. Changing the behaviour just for generic therefore
does not make sense.
Are you sure? That sounds more like -mcpu=native than -mcpu=generic.
AFAICT, -mcpu=generic always selects base Armv8 with generic tuning (i.e. the
default choice for default configure-time arguments).
It sounds like the use case here is to nullify the effect of a previous -mcpu,
a bit like "-mno-cpu" would if it was allowed. If so, I guess that would need
to be a new option. But could you test using:
"make check
RUNTESTFLAGS="--target_board=unix/{,-march=armv8.2-a+.../-mtune=octeontx2}"
instead? It's more awkward to specify, but probably easier than making sure
that the "-mno-cpu" equivalent is used in every test that needs it.
Thanks,
Richard
My apologies, yes, you're right. I was thinking about 'native' rather
than generic.
However, the real problem is that -mcpu=generic is (and always has been)
misnamed. Generic what? What it should have is an architecture version
in the name directly, so generic-armv8-a, generic-armv8.1-a, etc.
R.
