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

[Renato Golin]

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.


> 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