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

Ping. Can I assume that we're ok with this interface proposal then? 

 

Amara
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140127/49962cbc/attachment.html>

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

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>