<div dir="ltr">Hi,<div><br></div><div><br></div><div>Recently, I committed a patch adding default features for '-mcpu'. And after that, Eric replied me here's a proposal toward using '<font face="arial, sans-serif">-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 </font><span style="font-family:arial,sans-serif">what instruction sets does </span><font face="arial, sans-serif">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</font><span style="color:rgb(50,50,50);font-family:Arial,宋体,微软雅黑;font-size:14px;line-height:16px;white-space:nowrap"> if '-march=cyclone'</span><span style="font-family:arial,sans-serif">  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 </span>architecture level <font face="arial, sans-serif">feature to point out </font><font face="arial, sans-serif">explicit instruction sets to get better portability among CPUs based on AArch64.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">To select CPU type as optimizing target, I suggest to use '-mtune', which indicates macro </font><span style="font-family:arial,sans-serif">architecture information to get fully </span><span style="font-family:arial,sans-serif">optimization for it. </span><span style="font-family:arial,sans-serif">'-mtune' won't automatically change any </span>architecture<span style="font-family:arial,sans-serif"> </span>level<span style="font-family:arial,sans-serif"> </span>feature selection, but will enable some macro <span style="font-family:arial,sans-serif">architecture feature </span><span style="font-family:arial,sans-serif">according to CPU</span><span style="font-family:arial,sans-serif">. For example, '-mtune=cyclone' won't enable crypto, but will enable </span><font face="arial, sans-serif">zcm and zcz, and also enable all special pass and scheduler. </font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Last change is about '-mcpu'. If user don't care </font><span style="font-family:arial,sans-serif">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 </span><span style="font-family:arial,sans-serif">feature of XXX+</span><span style="font-family:arial,sans-serif">[no]featureA -mtune=XXX</span><span style="font-family:arial,sans-serif">'. All default feature will get enabled and tune target will be selected. So it's just a short hand of '-march' and '-mcpu'.</span></div>
<div><span style="font-family:arial,sans-serif"><br></span></div><div><font face="arial, sans-serif">I think those changes can easily build binary running on multiple CPUs and get more compatible with gcc. </font><span style="font-family:arial,sans-serif;font-size:13.63636302947998px">Is this new proposal reasonable?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.63636302947998px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.63636302947998px">Best Regards,</span></div><div><span style="font-family:arial,sans-serif;font-size:13.63636302947998px">Kevin Qin</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.63636302947998px"><br></span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-01-27 18:49 GMT+08:00 Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class=""><div class="gmail_extra"><div class="gmail_quote">On 27 January 2014 10:29, Amara Emerson <span dir="ltr"><<a href="mailto:amara.emerson@arm.com" target="_blank">amara.emerson@arm.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:10.5pt;font-family:Consolas">Ping. Can I assume that we’re ok with this interface proposal then?</span></p>

</div></div></blockquote><div></div></div><br></div></div><div class="gmail_extra">Hi Amara,</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">cheers,</div><div class="gmail_extra">--renato</div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Regards,<div><br></div><div>Kevin Qin</div></div>
</div>