llvm dev - Jun 2014 - [LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal

On 25 June 2014 12:58, James Molloy <james at jamesmolloy.co.uk>
wrote:
> This is one of the worst parts about the Clang CLI for cross compilation at
> the moment. I'd really like, if we're changing the CLI, to allow
users to
> remove it. For example, if I specify -march=armv7-a, it *shouldn't*
need me
> to put "-target arm" before it to work!
Good lord, that's horrendous!

> On a similar note, how does this proposal deal with instruction set
> selection? what does "-march=armv8-a" select-  AArch32 or
AArch64? or is
> that expected to be handled by the "-target" (grim!)
Can't we do the same as -thumb? Like -a32 and -a64, with default to -a64?

--renato

On Wed, Jun 25, 2014 at 5:51 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 25 June 2014 12:58, James Molloy <james at jamesmolloy.co.uk>
wrote:
>> This is one of the worst parts about the Clang CLI for cross
compilation at
>> the moment. I'd really like, if we're changing the CLI, to
allow users to
>> remove it. For example, if I specify -march=armv7-a, it *shouldn't*
need me
>> to put "-target arm" before it to work!
>
> Good lord, that's horrendous!
>
*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)

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...

-eric

>
>> On a similar note, how does this proposal deal with instruction set
>> selection? what does "-march=armv8-a" select-  AArch32 or
AArch64? or is
>> that expected to be handled by the "-target" (grim!)
>
> Can't we do the same as -thumb? Like -a32 and -a64, with default to
-a64?
>
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

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