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

[James Molloy]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140625/e2750fee/attachment.html>