[llvm-dev] [RFC] New Clang target selection options for ARM/AArch64

[David Spickett via llvm-dev]

Hi Peter,

>> I think what Renato was meaning was that some CPUs already imply an
>> FPU and hence -mfpu is already "kind of" auto. For example
>> -mcpu=cortex-m4 implies a FPU.
>> ARM_CPU_NAME("cortex-m4", ARMV7EM, FK_FPV4_SP_D16, true, ARM::AEK_NONE)

Ok I understand now, I'm mixing up current and (possible) future features.

>> clang -mcpu cortex-a8 -mfpu vfp4 -mfpu auto ->defaults back to VFP3.

We would want to keep the current logic here. Which I've observed to be that the last mfpu wins, overriding the default from mcpu.

$ ./clang --target=arm-arm-none-eabi -mcpu=cortex-a8 -mfpu=vfpv4-d16 -mfpu=vfpv4 -c /tmp/test.c -o /tmp/test.o -###
<...> "-target-feature" "-d16" "-target-feature" "+vfp4" <...>
$ ./clang --target=arm-arm-none-eabi -mcpu=cortex-a8 -mfpu=vfpv4 -mfpu=vfpv4-d16 -c /tmp/test.c -o /tmp/test.o -###
<...> "-target-feature" "+d16" "-target-feature" "+vfp4" <...>
(vfp4-d16 wins)

So yes, with the explicit 'auto' you'd revert to the cpu provided fpu:

$ ./clang --target=arm-arm-none-eabi -mcpu=cortex-a8 -mfpu=vfpv4 -mfpu=auto -c /tmp/test.c -o /tmp/test.o -###
<...> "-target-feature" "-d16" "-target-feature" "+vfp3" <...>

(and without the 'auto' we'd emit a warning telling you that you overrode the 'vfpv3' from mcpu with 'vfpv4' from mfpu)

>> but it illustrates that there may be other projects that would be affected if we are too strict.

Definitely going to tread lightly when introducing new checks. Just having the option to enable them is a good place to start.

Thanks,
David Spickett.


________________________________
From: Peter Smith <peter.smith at linaro.org>
Sent: 26 September 2018 12:38:16
To: David Spickett
Cc: Renato Golin; llvm-dev; nd; Clang Dev
Subject: Re: [llvm-dev] [RFC] New Clang target selection options for ARM/AArch64

Hello David,

Not a lot to add over what Eli and Renato have already mentioned.

> 'auto' FPU value (Renato)
> ================
>
> >> I'd have assumed -mfpu is already "auto" by default. Or is this to
> >> just override a previous option?
> >>
> >> ex: clang -mcpu cortex-a8 -mfpu vfp4 -mfpu auto -> defaults back to VFP3.
>
> I don't see any reference to this in the code or the docs, and clang something similair:
> ./clang --target=arm-arm-none-eabi -mcpu=cortex-a8 -mfpu=vfp4 -mfpu=auto -c /tmp/test.c
> clang-8: error: the clang compiler does not support '-mfpu=auto'
>
> Maybe I'm missing something.
>

I think what Renato was meaning was that some CPUs already imply an
FPU and hence -mfpu is already "kind of" auto. For example
-mcpu=cortex-m4 implies a FPU.
ARM_CPU_NAME("cortex-m4", ARMV7EM, FK_FPV4_SP_D16, true, ARM::AEK_NONE)

I think the example "clang -mcpu cortex-a8 -mfpu vfp4 -mfpu auto ->
defaults back to VFP3." was a theoretical what if -mfpu=auto came
after an explicit -mpfu=vfp4, would this result in the default fpu
thus overriding the previous -mfpu=vfp4

> >> Define "incompatible". Older Arm cores could have new features that
> wasn't even define in its own standard because manufacturers upgraded
> the extra but not the core.
>
> Good point, I suppose "incompatible" in the way I wrote it means "not listed as an off the shelf config". Which you're right, doesn't cover everything. So yes, agreed on defaulting to warnings behind -Wall.
>
I think that post-cortex CPUs are far more locked down in terms of
configurations. If you have an FPU it will always be of the same type.
I agree with Renato that the outside world is considerably messier
than we'd like though. For example compiler-rt builtins for Cortex-m4
currently cheats and specifies a full double precision FPU as there
are some functions (never called and hence never included in a M4
binary but present in the archive) that use double precision floating
point. In compiler-rt's case I think that we should fix that but it
illustrates that there may be other projects that would be affected if
we are too strict.

Looking forward to seeing the results of the work.

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180927/b4e25cd3/attachment.html>