[PATCH] D24156: [CMake] Explicitly add --target option to compiler flags

[Renato Golin via llvm-commits]

rengolin added a comment.

Hi Chris,

Let me get my bearings on RT's CMake system...

With regards to `COMPILER_RT_DEFAULT_TARGET_TRIPLE`:

1. If it is extracted from the host's triple, than this won't help much.
2. If if comes from COMPILER_RT_TARGETS' "default triple" (whatever that is), we'll probably get it mostly wrong
3. If this comes from the compiler's own (which target the compiler describes itself as), than we'll get it mostly right
4. If it's possible to override, than we can work around the remaining cases

I don't think it's case 1, as it wouldn't make sense...

Case 2 would need a "list of default triples" in CMake, which won't get the ABI issue right.

Case 3 would be mostly correct because the GNU toolchain has names like "arm-linux-gnueabihf-gcc" or "arm-linux-androideabi-gcc", which also describes itself to "Target: arm-none-eabi" (via `arm-none-eabi-gcc -v`), which is close to what you want.

If we had some detection like case 3, we could use case 4 to fix the remaining issues.

Now, the important issue to consider is how run time libraries are normally used.

In the case of "gnueabhf", we already have most floating point instructions implemented in hardware, but not all calls in RT are FP, so you still want RT to provide you with the remaining cases.

But some toolchains build files assuming that run time libraries are always "soft-float", even though the target is "hard-float". For eample, Compiler-RT's implementations for floating point (libs/builtins/arm) use R0 instead of D0. But this is not always the case, and depends on the toolchain, optimisation levels or available libraries.

So, defaulting to "whatever the toolchain you're using identifies itself as" is a good strategy, and can take care of most cases. But being able to override, preferably using only one flag which gets passed along all the similar decisions, would be necessary to get the remaining cases correctly.

The case of "arm-none-eabi" is even more complicated (but in a way, simpler - bear with me).

That triple is a generic triple that defaults to "ARMv4 soft-float". But embedded targets can be anything, so it's almost *always* the case (unless you're using StrongARM) that you'll change the meaning of the triple via flags, which the toolchain will **not** tell you directly.

This may seem impossible to get it right, but users end up having to pass the triple **and** a lot of architecture flags to define what they want. And, just like magic, if you pass the triple **and** the flags, the library will hopefully, be compiled as expected.

All in all, library developers/users **know** what they want and how to get it. We just need to give them a way to do so with the minimal amount of flags. If they want an embedded target with a generic library but a heavily optimised ARMv7A+NEON source that calls libraries as soft-float, they'll know how to get that. We just need to allow them to build the run time libraries in a way they expect.

On that topic, I think @compnerd can help you outline all the weird way people build run time libraries, but probably a bit too much for this patch.

cheers,
--renato


https://reviews.llvm.org/D24156