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

[Peter Smith via llvm-dev]

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