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

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

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/llvm-dev/attachments/20140625/e2750fee/attachment.html>

On 25 Jun 2014, at 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!
One thing that I've been pondering for a little while is making clang's
use of the triple a config file.  In particular, we'd like to invoke things
like mips4-unknown-freebsd-clang and have it really mean 'clang -target
mips64-unknown-freebsd -mcpu=mips4 -msoft-float
--sysroot=/usr/local/sysroots/mips4 {whatever}'.  For cross compiles,
we'd only need one clang, a symlink, and a config file.  I pondered a more
structured config file, but really there isn't much that we'd want to do
that isn't already covered by command-line arguments, so just having it look
for ${LOCALBASE}/etc/llvm/mips4-unknown-freebsd-clang.conf would be fine.

We can do this via shell scripts now, but even with exec the extra shell
invocation has a measurable overhead and in some cases (e.g.
i386-unknown-freebsd-clang on FreeBSD/x86-64) we'd like to just use the
default values for the triple.

David

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

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/llvm-dev/attachments/20140626/bea327f8/attachment.html>