"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
