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

Hi,


Recently, I committed a patch adding default features for '-mcpu'. And
after that, Eric replied me here's a proposal toward using '-march'
instead
of '-mcpu'. As it's half a year later from original proposal, some
background may changes. One thing worth to mention is, during this time,
Apple Contributed its backend and introduced another new CPU type: cyclone.
Now, AArch64 target supports 4 kinds of CPU types: cyclone, cortex-a53,
cortex-a57 and generic. First three cover full feature from fp to crypto,
and for generic, only fp and neon are enabled by default. As time goes by,
more and more CPU types will be introduced with different combination of
features. Then, the end-user may not have knowledge to find out what
instruction sets does each CPU support. So from my point of view, it's not
quite wise to put CPU names into '-march'. '-march' should only
select
architecture level feature, which means decide instruction sets. If a
binary is complied by '-march=+neon+crypto', then it should be able to
run
on all CPU supporting neon and crypto. And end-user won't need to doubt if
'-march=cyclone'  can safely run on another CPU without crypto, like
generic(This kind of CPU will quite possibly be reality in future). In
summary, I suggest '-march' only accept architecture level feature to
point
out explicit instruction sets to get better portability among CPUs based on
AArch64.

To select CPU type as optimizing target, I suggest to use '-mtune',
which indicates macro architecture information to get fully optimization
for it. '-mtune' won't automatically change any architecture level
feature
selection, but will enable some macro architecture feature according to CPU.
For example, '-mtune=cyclone' won't enable crypto, but will enable
zcm
and zcz, and also enable all special pass and scheduler.

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 those changes can easily build binary running on multiple CPUs and
get more compatible with gcc. Is this new proposal reasonable?

Best Regards,
Kevin Qin



2014-01-27 18:49 GMT+08:00 Renato Golin <renato.golin at linaro.org>:
> On 27 January 2014 10:29, Amara Emerson <amara.emerson at arm.com>
wrote:
>
>> Ping. Can I assume that we’re ok with this interface proposal then?
>>
>
> Hi Amara,
>
> Sorry, I got no replies from the GCC folks. I think we all agree that this
> is a good way forward, so let's just go with it and try to keep
> compatibility as an equally important, but secondary goal.
>
> cheers,
> --renato
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

-- 
Best Regards,

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

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

On 25 June 2014 08:26, Tim Northover <t.p.northover at gmail.com>
wrote:
> 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.
Agreed.

> 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.
Not entirely true. Legacy systems will be easily migrated to AArch64
by replacing previous flags with updated values (possibly migrated
from even older values still).

I'm fairly certain that GCC will enable any kind of legacy options,
which will encourage people to keep using it and complain that Clang
doesn't, and you know the rest of the story.

We could label them "lazy" but whoever had to deal with build
systems'
crap knows how hard it is to make even the smallest of changes to a
legacy system already migrated twice. The guys that wrote the original
are all dead and your life is not long enough.

I'm not advocating to keep legacy, only that we think about it. Clang
already has the pretend-GCC-behaviour in many ways, and if that is
implemented orthogonally from the modern compiler (facade pattern for
those GOF-inclined), than we won't have to break our compiler but
still understand legacy for its merits.

One way to do this is to make triple/mcpu/mfpu parsing a way of
setting flags, and then feeding the flags back to -cc1, so that -cc1
doesn't have triples/mcpu/mfpu by definition.

>> 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!
+1.

--renato

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>