[LLVMdev] Target Triple Changes

[Renato Golin]

Hi all,

There's been some controversies in the TargetTriple changes and I want
to explain it better in the list (to a wider audience) and also
propose my plans on how to support the ARM platform better, especially
cross-compilation in Clang.

All this discussion came as a spin-off of bug 8911
(http://llvm.org/bugs/show_bug.cgi?id=8957)...

Today we have three major problems in cross-compiling to ARM with Clang:

 1. Some ARM triples "arm*-none-eabi" don't get properly recognized,
so Clang doesn't generate correct AAPCS (soft and hard) calls and
don't pass the correct triple to LLC.

 2. Some options in Clang are chosen by parsing the triple directly,
because triples don't have all properties necessary to make such
decisions.

 3. Clang today has only host-triple, which is inaccurate to describe
a cross-compilation  environment, when the difference between the host
and the target matters when the driver is choosing what to run and
what options to pass.


To fix that, I think we needs three things:

 1. Adding the options to the triple, so EABI can be recognized and
properly stored to avoid string comparisons. This is not as simple as
it seems because "arm-none-eabi" actually puts EABI in the OS slot,
and the triple validation breaks before it gets to parsing the
environment, because OS is actually invalid. There are some
alternatives (such as split: normalization / validation and do special
fiddling in between) but the main problem is that the triple logic is
not written in stone and different vendors use different styles.

 2. Clang parses - if arch.contains("v6") - which is not ideal. Clang
should have a localized parse for sub-architectures (only important
for ARM, I believe) and fill in TargetData objects with all
information it can gather (by also using the other triple properties)
to make every IR / command line generation decision based on that. I
don't know why Clang calls LLC with command line options instead of
just calling the back-end directly passing the TargetData, but it
doesn't make that much difference.

 3. Once all that support is in place, implement a target triple and
use it for codegen/cmd-line choices, while the host triple is still
used to choose what binaries to call by the driver.

I hope all that makes sense, and if so, I plan on working on that.

-- 
cheers,
--renato