[llvm-dev] [RFC] New Clang target selection options for ARM/AArch64 (original) (raw)

Peter Smith via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 26 04:38:16 PDT 2018

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

More information about the llvm-dev mailing list