[LLVMdev] Target Triple Changes

[Renato Golin]

On 23 January 2011 13:33, Duncan Sands <baldrick at free.fr> wrote:
> in order to have "eabi" be properly recognized by LLVM, it is enough to
> add "eabi" as a valid environment value.  Then Triple::Normalize will
> automatically move eabi to the environment position, resulting in
> arm*-none--eabi  So I think this is easy to take care of.

That could work, if Clang/LLVM could work around the "--" issue. When
looking for "arm-none-eabi.gcc", clang would never find a
"arm-none--eabi-gcc". We could do a "canonicalTriple" to print the
proper way (with two dashes) and a "compressedTriple" printing the
expected by GCC. That would make my change in the normalization
redundant, but would require some cleanup in Clang (which I'm not that
familiar). But I think this is also not the best way to fix the
problem, see below...


> I think that's a good thing!  Clang's needs are different to LLVM's, so
> probably clang should have it's own ClangTriple class.  Given a triple
> string you probably first want to have Triple::Normalize crunch on it,
> permuting recognized components into the correct positions, and then
> have ClangTriple apply additional logic.

I agree that Clang has different needs and probably ClangTriple should
extend Triple in that way, but that's not what's happening. Clang
parses independently and messes up when passing the triple back to
LLC. It should keep the triple intact or parse it completely,

And, given that Clang only parses triples from the command-line and
LLVM only parses it from the IR, if the parser is different (ie, when
Clang passes it via command-line to llc) , you might get different
results from the LLVM's parser (Triple) and the Clang parser
(ClangTriple -> Triple).

Adding the fact that Clang calls LLC instead of invoking the back-end
directly using TargetData and setting the rest of the options
directly, we have a design decision in our hands, that I was expecting
to delay to the second cycle.

In my view, there are two ways of doing this:

 1. Have a very basic Triple class (removing the Env-to-OS feature
I've added), extending ClangTriple to parse ARM sub-architectures,
Env-to-OS idiosyncrasy and create a TargetData object from the
difference between ClangTriple and Triple, and setting all
sub-architecture parameters (AAPCS, EABI, VFP, hardFP, softFP, etc)
directly on the back-end properties and invoking the back-end
directly.

 2. Have Clang to call LLC via command-line, where we're forced to
have the same triple parser for both cases (LLVM's Triple), or face
the difference in attributes when coming from Clang or LLC directly
via command line.

I prefer the first path, but I have actually coded the second. Why?
Because I didn't want to break everything. I just wanted to add EABI
to Environment, but that brought all the other problems. So I had a
choice: either re-factor the whole Clang-LLC interaction or do the
required modification to have it working with the current design, even
if it was a bit ugly.

To be honest, this change doesn't fix our cross-compilation problems,
but it was the first toe in the cold water, to get *precisely* the
feed-back you're giving us... ;)

Hope this makes things a bit more clear.

cheers,
--renato