<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks for the explanation. I'm own next response may be slow as I'm off for Christmas after tomorrow, but let's carry on the discussion for a moment.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>My main issue here is compatibility of AArch32 and AArch64 in clang. I think we agree that that's achievable, even if it ends up being in one direction only (i.e. AArch32 must be able to consume AArch64 CLI, but not necessarily the other way around).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>But there is still the issue of GCC compatibility. Sure, LLVM is the only compiler targeting real AArch64 hardware right now, but that will change and AArch64 Linux is already available for virtual targets (e.g. through Linaro). I don't think GCC is going to change to match clang and I think we (the clang/LLVM community) want people to be able to use clang to compile their 64-bit Linux applications.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>AArch64 GCC does still use -march/-mcpu/-mtune. I understand that -march specifies what is legal to do and is limited to taking 'architecture' values, with modifications for optional features (e.g. -march=armv8-a+nocrypto). -mtune specifies what to optimize for and takes CPUs as arguments. -mcpu also takes CPUs as arguments and is a shorthand for the other two options, so -mcpu=cortex-a53 is equivalent to -march=armv8-a -mtune=cortex-a53. Whether or not this makes sense, it is what GCC does.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>So, if we want to be compatible with GCC, we have to support these options.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Eric Christopher [mailto:echristo@gmail.com] <br><b>Sent:</b> 16 December 2013 23:36<br><b>To:</b> Bernard Ogden; Nigel Stephens; t.p.northover@gmail.com; Amara Emerson; cfe-commits@cs.uiuc.edu<br><b>Subject:</b> RE: r193740 - [AArch64] Add some CPU targets for "generic", A-53 and A-57.<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>I apologize for the delay in replying here.<o:p></o:p></p><div><p class=MsoNormal>On Tue Nov 19 2013 at 1:00:33 AM, Bernard Ogden <<a href="mailto:Bernard.Ogden@arm.com">Bernard.Ogden@arm.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal style='margin-bottom:12.0pt'>I find the compatibility arguments more compelling than you do :)<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>To be clear you want compatibility with ARM32 here, not necessarily with gcc (since you "ARM" added the gcc code and there's no existing toolchains that target hardware outside of llvm).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal style='margin-bottom:12.0pt'>More specifically -<br><br>* GCC compatibility is a goal of the clang driver. Targeting is inherently different so perhaps we shouldn't worry too much about that in this case. I don't see the pain that justifies making the break in this case, but I'm willing to believe it is there.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I don't think this is a valid argument here as I explained above.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal style='margin-bottom:12.0pt'>* AArch32 compatibility is important to me. I really don't want users to have to learn subtly different CLIs to compile code to run on any two ARM cores, let alone to run in different execution states on a single core.<br><br>Let's set aside GCC compatibility for now. We could get to the behaviour you want without breaking AArch32 compatibility by deprecating -mcpu for the ARM backend and updating -march to take the CPUs as well (and adding -mtune?). We would then have:<br><br>AArch64: Target selection via -march and -mtune only<br>AArch32/ARM: Target selection via -march, expanded to take CPU names as well, and -mtune. -mcpu remains but is deprecated.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I can agree with this.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal style='margin-bottom:12.0pt'>The AArch64 backend is therefore not GCC compatible, but you argue this doesn't matter. The AArch32 backend becomes compatible with both GCC and AArch64. We lose GCC compatibility if we discard -mcpu one day, but perhaps GCC itself will change.<br><br>I could live with this - I've not been here long enough to have a sense of what the wider community will think.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In general, I think that the existing ARM behavior in gcc is a mistake. I complained about it a decade ago :)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Let's see if an example helps:<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal style='margin-bottom:12.0pt'><br>As for the rest, I'm getting lost in terminology. cpu and arch seem to mean slightly different things depending on toolchain and I'm not all that steeped in GNU ways. But I think you're proposing that the triple should identify a backend/architecture 'family', and identification of either a specific architecture version or a cpu should be set by -march. This sounds reasonable enough to me - though I think the main value is in having a single set of rules for how target selection works, almost regardless of what the specifics are. So long as they're not too crazy.<br><br>While we're on this subject, what would you expect -march=armv7/armv8 to mean? The current behaviour in the ARM backend is to set a default CPU to represent the arch, so armv7a, for instance, means cortex-a8. Similarly, the v8 backend assumes NEON and FP are present, which is likely but not architecturally guaranteed. This kinda gives a 'pragmatically useful' set of subtarget features, but certainly won't produce code guaranteed to run on any valid implementation of the architecture. I don't necessarily have a problem with this, I'd just like to know if you think this is fine, or if this is something else you would like to see change?<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'm going to summarize a bit here on what most targets do in case it helps:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-march handles the particular cpu features you'd like to target. There are then additional -m<foo> options that handle the specific cpu features that can then be enabled/disabled via this. As an example from x86:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-march=core-i7 -mno-sse<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Will target a core-i7 processor, but leave out the sse instructions. You can see the parallel with -march=cortex-a7 -mfpumath=neon (or however it's spelled).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The default tuning for this will be for a core-i7. But let's say you don't want to do that, you actually want your code to be tuned for a haswell and not a generic i7 (though it needs to run across multiple architectures so you set the minimum hardware requirements via -march) you'd then do something like:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-mtune=haswell<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>and you'd have something scheduled/instruction selected for a haswell, but only using the hardware features specified by the -march and -m options above.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Make sense?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Basically, in general, there's no existing set of makefile/build targets for aarch64 in the wild - there aren't any -march/-mcpu/-mtune sets going on, it's a new architecture and now's a good time to set the specific command line that should be supported. :)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-eric<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal style='margin-bottom:12.0pt'>Regards,<br><br>Bernie<br><br><br>> -----Original Message-----<br>> From: Eric Christopher [mailto:<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>]<br>> Sent: 19 November 2013 03:06<br>> To: Bernard Ogden<br>> Cc: Nigel Stephens; Tim Northover; Amara Emerson; cfe-<br>> <a href="mailto:commits@cs.uiuc.edu" target="_blank">commits@cs.uiuc.edu</a><br>> Subject: Re: r193740 - [AArch64] Add some CPU targets for "generic", A-<br>> 53 and A-57.<br>><br>> On Tue, Nov 12, 2013 at 4:39 AM, Bernie Ogden <<a href="mailto:bogden@arm.com" target="_blank">bogden@arm.com</a>> wrote:<br>> > I'm still not sure what the point at issue is.<br>> ><br>><br>> Names are important. Not having confusing names is even more important.<br>><br>> > Based on a recent copy of the GCC manual and a little checking of CLI<br>> > behaviour in recent Linaro releases, my understanding of the GCC<br>> behaviour<br>> > for both AArch32 and AArch64 is:<br>> ><br>> > march: Takes an architecture such as armv8-a, with optional feature<br>> > modifiers. Rejects CPU names. Determines which instructions can be<br>> selected.<br>> ><br>> > mcpu: A CPU such as cortex-a53, with optional feature modifiers.<br>> Rejects<br>> > arch names. Determines which instructions can be selected.<br>> ><br>><br>> This duplication is a serious pain. This is what I want to remove and<br>> what I wanted to remove when I worked on gcc in the past.<br>><br>> > mtune: Like mcpu, but does not take feature modifiers and determines<br>> which<br>> > optimizations should be applied rather than which instructions should<br>> be<br>> > selected.<br>> ><br>> ><br>> > So I think the suggestion is that -mcpu should be dropped. But this<br>> would be<br>> > a GCC compatibility break, which I thought was considered<br>> undesirable?<br>> > Having -march take CPU names would also be incompatible, but I think<br>> that<br>> > that's a detail, not the main issue.<br>> ><br>><br>> Given that the only shipping aarch64 hardware in the world shipped<br>> with llvm I think the precedent should be there to match the shipping<br>> llvm compiler. :)<br>><br>> As far as I know there aren't any shipping aarch64 compilers using gcc<br>> targeting hardware and there's not a huge history here anyhow for<br>> people to be confused.<br>><br>> > Have I understood all of this correctly? If not, I would be grateful<br>> if<br>> > someone would set me straight.<br>> ><br>><br>> Yes.<br>><br>> > I would like the two ARM flavours to behave consistently in<br>> clang/LLVM. I'm<br>> > not sure right now what the AArch32 side does with mtune/march, but I<br>> > suspect it's not quite what GCC does - I think clang probably ignores<br>> the<br>> > former and implicitly selects a CPU for the latter. If we want to do<br>> > something with -march/-mtune on one side, let's do it on the other<br>> too, and<br>> > in the same way.<br>><br>> Sounds good to me here - in that I think gcc should change.<br>><br>> ><br>> > I think not supporting -mcpu in AArch64 would add no value and would<br>> break<br>> > compatibility with both GCC and with LLVM AArch32, so would be a Bad<br>> Thing.<br>> > But perhaps I'm just ignorant - I'm happy to be educated.<br>> ><br>><br>> I don't see much win in gcc compatibility here and there's no gain for<br>> AArch32 - they're just different architectures, let's make a good<br>> clean start.<br>><br>> As a thought I look at -mcpu like I would the cpu part of a gnu<br>> triple, i.e. -mcpu will change the beginning of the triple:<br>><br>> -march=arm64<br>><br>> would get you a triple of arm64-apple-darwinNN<br>><br>> on darwin.<br>><br>> I think The Ideal Way(tm) is to use a -target flag with a full triple<br>> and any particular architecture should go on as function attributes.<br>> We're not there yet, but there's definitely work going that direction.<br>> In general, this sort of thing is going to be a problem that we're<br>> going to need to fix as universal cross compilation is becoming more,<br>> not less important.<br>><br>> That said, for now, the cpu is part of the triple and the particular<br>> architecture supported is passed via -target-cpu. There's no reason<br>> for not compiling for -target aarch64-linux-gnu and -march=cortex-a53.<br>> It's no different than compiling for a generic mips32r2 cpu and would<br>> allow you to be as specific as you like. What compelling argument is<br>> there for -mcpu existing?<br>><br>> -eric<br>><br>> ><br>> >> -----Original Message-----<br>> >> From: Nigel Stephens<br>> >> Sent: 11 November 2013 20:49<br>> >> To: Eric Christopher<br>> >> Cc: Tim Northover; Bernard Ogden; Amara Emerson; cfe-<br>> >> <a href="mailto:commits@cs.uiuc.edu" target="_blank">commits@cs.uiuc.edu</a><br>> >> Subject: Re: r193740 - [AArch64] Add some CPU targets for "generic",<br>> A-<br>> >> 53 and A-57.<br>> >><br>> >><br>> >><br>> >> > On 11 Nov 2013, at 07:24 pm, "Eric Christopher"<br>> <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>><br>> >> wrote:<br>> >> ><br>> >> > On Fri, Nov 8, 2013 at 9:02 AM, Tim Northover<br>> >> <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>> wrote:<br>> >> >>> To me it would be odd if the AArch64 CLI behaved differently to<br>> >> AArch32,<br>> >> >>> except where absolutely necessary.<br>> >> >><br>> >> >> The general GCC interface has been encouraging -march/-mtune for<br>> >> years<br>> >> >> now. I've no idea what reasons 32-bit ARM chose to go against<br>> that,<br>> >> >> but I'd want to make sure they were valid for AArch64 before<br>> >> >> perpetuating it.<br>> >> >><br>> >> >> Inertia doesn't seem like a great reason except for ARM-only<br>> >> projects,<br>> >> >> which are fairly rare.<br>> >> ><br>> >> > I agree with all of this.<br>> >><br>> >> Likewise.<br>> >><br>> >> The march/mtune mechanism seems to be the correct model, so long as<br>> >> it's clear that march specifies the base architecture name (I.e.<br>> what<br>> >> instructions/features are available to the compiler), and mtune a<br>> >> specific CPU name (I.e. how do those instructions behave on a<br>> specific<br>> >> microarchitecture). Confusion can reign if these get reversed!<br>> >><br>> >> Nigel<br>> ><br>> ><br>> ><br><br><br>-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.<br><br>ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590<br>ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782<o:p></o:p></p></blockquote></div></div></body></html>