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

[Kevin Qin]

Hi James,

I understand the annoyance from '-target'. I can do something around this
to override triple from '-march', but the trouble is how to define default
value for OS and ABI? Now I can give 2 solutions:

A. Get OS and ABI from host triple. For example, If host triple is
"x86_64-unknown-linux-gnu", then using '-march=armv8-a' without specifying
'-target' will give 'aarch64-unknown-linux-gnu'.
B. Use "unknown" value for OS and ABI. Then '-march=armv8-a' equals to
'-target=aarch64', which represents  'aarch64-unknown-unknown'.

For solution A, it can bring convenience to user running same operation
system on host and target device, but also introduce uncertain "environment
flag" to command line, which may cause confusion when migrating build system
to other OS.
For solution B, it seems more reasonable. But I doubt this kind of triple
is really useful.

Do you have any good idea?

Regards,
Kevin


2014-06-25 19:58 GMT+08:00 James Molloy <james at jamesmolloy.co.uk>:

> Hi Kevin,
>
> > Because triple is necessary for clang and it have selected the
> architecture.
>
> 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!
>
> 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!)
>
> Cheers,
>
> James
>
>
> On 25 June 2014 09:02, Kevin Qin <kevinqindev at gmail.com> wrote:
>
>> Hi Tim,
>>
>>
>>
>>
>> 2014-06-25 15:26 GMT+08:00 Tim Northover <t.p.northover at gmail.com>:
>>
>> Hi Kevin,
>>>
>>> I assume you've looked at the GCC documentation in this area, since
>>> your ideas are very similar:
>>> https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html. I actually
>>> think that looks like a rational set of conventions too.
>>>
>>> The main difference appears to be that GCC requires "armv8-a" in
>>> -march before any features, which I quite like. But even if I didn't
>>> it's close enough that we should follow anyway, for compatibility if
>>> nothing else.
>>>
>> In my plan,  "armv8-a" "arm64" and "aarch64" are optional architecture
>> name for '-march'. Because triple is necessary for clang and it have
>> selected the architecture. If one day there's another architecture is
>> introduced, architecture would be decided by triple at first, and can
>> be overridden if architecture is specified by '-march'.
>>
>>>
>>> > Last change is about '-mcpu'. If user don't care portability and only
>>> want
>>> > to get good performance on a certain CPU, he can use
>>> > '-mcpu=XXX+[no]featureA', which is an alias of '-march=default feature
>>> of
>>> > XXX+[no]featureA -mtune=XXX'. All default feature will get enabled and
>>> tune
>>> > target will be selected. So it's just a short hand of '-march' and
>>> '-mcpu'.
>>>
>>> I think we should also specifically warn on the use of -mcpu:
>>> aggressively deprecate it on AArch64. AArch64 is a new architecture,
>>> there's no real excuse for using the legacy options.
>>>
>> Agreed.
>>
>>>
>>> > I think those changes can easily build binary running on multiple CPUs
>>> and
>>> > get more compatible with gcc. Is this new proposal reasonable?
>>>
>>> I like it!
>>>
>>> Cheers.
>>>
>>> Tim.
>>>
>>
>>
>>
>> --
>> Best Regards,
>>
>> Kevin Qin
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>


-- 
Best Regards,

Kevin Qin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140626/bea327f8/attachment.html>