[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal

[Eric Christopher]

On Thu, Jun 26, 2014 at 5:27 AM, Renato Golin <renato.golin at linaro.org> wrote:
> On 25 June 2014 23:24, Eric Christopher <echristo at gmail.com> wrote:
>> *shrug* it's that or we start figuring out how to make -arch work on
>> all hosts to all targets. (Hint: Not possible without a triple)
>
> Everything is "possible". :)
>
> My view is that there are many poor solutions, like triples, but that
> triples have already been abused so much that the other poor ones are
> looking a little better. The legacy in triples makes dealing with edge
> cases a lot harder.
>

This is where you choose simplicity rather than trying to lump
everything into a triple. -march and the various feature flags
can/should work on top of a basic triple to do everything.

-eric

>
>> i.e. if you specify -march=armv7-a what OS do you want? You could say
>> that you want the same OS that you're on I guess, but...
>
> That's where it gets complicated... From x86_64 to x86, yes, I would
> assume the environment is the same, but from x86 to ARM, I wouldn't.
> To have that kind of logic on the triple parsing code would be
> nefarious.
>
> Another example is the case where "-triple armv7-linux-gnueabi -thumb"
> becomes "-triple thumbv7-linux-gnueabi" within the driver, and
> getArchCPU() returns "cortex-a8" in the first two times it's called
> and "arm7tdmi" for the last, which end up being the CPU of choice.
> This is a bug, yes, but it's a result of having triples being used as
> input AND data structure AND output to -cc1 in the driver.
>
> That's why I suggested to have a clean triple parser, that only parses
> triples and produces arch+flags, which will then be passed to the
> -cc1. David's configuration files could have the exact same effect and
> even be pluggable on the driver in the same way the triple parsing and
> -march+flags does. A GNU compatibility layer would also be easy to
> implement that way, and be completely separated from pure-Clang
> parsing, if that infrastructure would exist.
>
> But I've seen the code that deals with flags and triples and it has
> more hard-coded flag-guessing that lines of code, so I'm not sure
> anyone would be willing to do that refactoring... :(
>
> cheers,
> --renato