<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=iso-8859-1">

<meta name="Generator" content="Microsoft Word 14 (filtered medium)">

<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}

o\:* {behavior:url(#default#VML);}

w\:* {behavior:url(#default#VML);}

.shape {behavior:url(#default#VML);}

</style><![endif]--><style><!--

/* Font Definitions */

@font-face

        {font-family:Wingdings;

        panose-1:5 0 0 0 0 0 0 0 0 0;}

@font-face

        {font-family:"Cambria Math";

        panose-1:2 4 5 3 5 4 6 3 2 4;}

@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;}

p

        {mso-style-priority:99;

        margin:0cm;

        margin-bottom:.0001pt;

        font-size:12.0pt;

        font-family:"Times New Roman","serif";}

p.MsoAcetate, li.MsoAcetate, div.MsoAcetate

        {mso-style-priority:99;

        mso-style-link:"Balloon Text Char";

        margin:0cm;

        margin-bottom:.0001pt;

        font-size:8.0pt;

        font-family:"Tahoma","sans-serif";}

span.EmailStyle18

        {mso-style-type:personal-reply;

        font-family:"Calibri","sans-serif";

        color:#1F497D;}

span.BalloonTextChar

        {mso-style-name:"Balloon Text Char";

        mso-style-priority:99;

        mso-style-link:"Balloon Text";

        font-family:"Tahoma","sans-serif";}

.MsoChpDefault

        {mso-style-type:export-only;

        font-size:10.0pt;}

@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">I’d say that the only thing I consider to be stable about a triple is whether it represents little or big endian (I rejected the addition of a --with-endian

 configure time option from MIPS GCC a few months ago). Everything else from the triple is fuzzy at best. The debian multi-arch ‘tuples’ get as close as anything to well-defined triples but get ugly very quickly and have not been adopted by other distributions.<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">Matthew<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""> Daniel Sanders

<br>

<b>Sent:</b> 24 September 2015 00:05<br>

<b>To:</b> Eric Christopher; Renato Golin; Jim Grosbach<br>

<b>Cc:</b> llvm-dev@lists.llvm.org; Matthew Fortune<br>

<b>Subject:</b> RE: The Trouble with Triples<o:p></o:p></span></p>

</div>

</div>

<p class="MsoNormal"><o:p> </o:p></p>

<div>

<div>

<div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">> > The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will

 likely be incorrect.<o:p></o:p></span></p>

</div>

</div>

</div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">>

<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">> If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect.<br>

> If it's something that's overridden later because it can't be represented by a triple then that<br>

> default needs to be overriden. This make sense? My mipsel example is what comes to mind here the most.<br>

<br>

I think so although the triple is often incorrect, particularly with Triple::mips/mips64.<o:p></o:p></span></p>

</div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"><br>

> (Though, if you wouldn't mind, where did you get this mips-linux toolchain that had a<br>

> --target=mips-linux-gnu at gcc compile time, but was somehow little endian? How did<br>

> the little endianness get configured in?)<br>

<br>

It used to be found at <a href="http://community.imgtec.com/developers/mips/tools/compilers/clang-llvm/" target="_blank">

http://community.imgtec.com/developers/mips/tools/compilers/clang-llvm/</a> but that link (thankfully) redirects to our main page now which in turn links to llvm.org. I'm not sure how long it was our published LLVM+GCC toolchain since I only found out when

 a user asked about it.<o:p></o:p></span></p>

<div>

<div class="MsoNormal" align="center" style="text-align:center"><span style="color:black">

<hr size="2" width="100%" align="center">

</span></div>

<div id="divRpF639914">

<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"> Eric Christopher [echristo@gmail.com]<br>

<b>Sent:</b> 23 September 2015 23:23<br>

<b>To:</b> Daniel Sanders; Renato Golin; Jim Grosbach<br>

<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>; Matthew Fortune<br>

<b>Subject:</b> Re: The Trouble with Triples</span><span style="color:black"><o:p></o:p></span></p>

</div>

<div>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black"><o:p> </o:p></span></p>

<div>

<div>

<p class="MsoNormal"><span style="color:black">On Wed, Sep 23, 2015 at 3:00 PM Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com" target="_blank">Daniel.Sanders@imgtec.com</a>> wrote:<o:p></o:p></span></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">

<div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">> > Note that the same problems exist and that they are unrelated to the existence<br>

> > of TargetMachine or not since TargetMachine gets the relevant information from<br>

> > the Triple it  holds. This information is incorrect, even as a starting point.<o:p></o:p></span></p>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">>

<o:p></o:p></span></p>

</div>

</div>

</div>

<div>

<div>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">> I believe we're going to disagree here as the TargetMachine does not get all of its<br>

> information from the Triple - except where the Triple is the canonical place for that<br>

> information and it isn't overridden in any way.<o:p></o:p></span></p>

</div>

</div>

</div>

<div>

<div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will

 likely be incorrect.<o:p></o:p></span></p>

</div>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect. If it's something that's overridden later because it can't be represented by a triple then that default needs

 to be overriden. This make sense? My mipsel example is what comes to mind here the most.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">(Though, if you wouldn't mind, where did you get this mips-linux toolchain that had a --target=mips-linux-gnu at gcc compile time, but was somehow little endian? How did the little endianness get configured in?)<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></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">

<div>

<div>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">Are you saying that almost everything up to and including the architecture (e.g Triple::mips) should be represented directly in the

 (MC)TargetMachine?<o:p></o:p></span></p>

</div>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">I'm saying it should be one way or another yes.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></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">

<div>

<div>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">> I think Matthew is going down the correct path in his email and I've responded there.<o:p></o:p></span></p>

</div>

</div>

</div>

<div>

<div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">I have some questions on that but I'll reply there.<o:p></o:p></span></p>

</div>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">Cool deal.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">-eric<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></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">

<div>

<div>

<div>

<div class="MsoNormal" align="center" style="text-align:center"><span style="color:black">

<hr size="2" width="100%" align="center">

</span></div>

<div>

<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"> Eric Christopher [<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>]<br>

<b>Sent:</b> 23 September 2015 22:28</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

<div>

<div>

<div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"><br>

<b>To:</b> Daniel Sanders; Renato Golin; Jim Grosbach</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

<div>

<div>

<div>

<div>

<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">Cc:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">

<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Matthew Fortune</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

<div>

<div>

<div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"><br>

<b>Subject:</b> Re: The Trouble with Triples</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

<div>

<div>

<div>

<div>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black"><o:p> </o:p></span></p>

<div>

<div>

<p class="MsoNormal"><span style="color:black">On Wed, Sep 23, 2015 at 2:19 PM Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com" target="_blank">Daniel.Sanders@imgtec.com</a>> wrote:<o:p></o:p></span></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">

<div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">Rewrote the ABI example in terms of clang -cc1as which is a supported tool.<o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">Which is still just calling the same set of APIs I mentioned in my previous email so everything there still holds.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></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">

<div>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">Note that the same problems exist and that they are unrelated to the existence<br>

of TargetMachine or not since TargetMachine gets the relevant information from<br>

the Triple it  holds. This information is incorrect, even as a starting point.<o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">I believe we're going to disagree here as the TargetMachine does not get all of its information from the Triple - except where the Triple is the canonical place for that information and it isn't overridden in any

 way.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">I think Matthew is going down the correct path in his email and I've responded there.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">Thanks!<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">-eric<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></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">

<div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">Please do read the other examples in my previous email. It contains a number of problems<br>

that need to be addressed and are completely unrelated to the MC layer.<br>

<br>

ABI<br>

 <br>

Let's start at ExecuteAssembler() in cc1as_main.cpp. Here's a sketch of what happens:<br>

* Call TargetRegistry::lookupTarget() to get a llvm::Target.<br>

* Call createMCRegInfo(Triple, ...)<br>

* Call createMCAsmInfo(..., Triple)<br>

  * MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el)<br>

  * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el<br>

  * MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes

 (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32.<br>

* Construct an MCObjectFileInfo<br>

* InitMCObjectFileInfo()<br>

  * FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el)<br>

  * PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding.<br>

* Call createMCInstrInfo<br>

* Call createMCSubtargetInfo(Triple, ...)<br>

* If emitting assembly:<br>

  * Call createMCInstPrinter(Triple, ...)<br>

  * If emitting encodings:<br>

    * Call createMCCodeEmitter()<br>

    * Call createMCAsmBackend(..., Triple, ...)<br>

  * Call createMCAsmStreamer()<br>

* If emitting objects:<br>

  * Call createMCCodeEmitter()<br>

  * Call createMCAsmBackend(..., Triple, ...)<br>

  * createMCObjectStreamer()<br>

    * This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsAsmBackend and ultimately comes from Triple::mips/mipsel vs Triple::mips64/mips64el. This is incorrect for N32 (which should be ELF32 but

 has Triple::mips64/mips64el) and for mips-linux-gnu –mips64 (which should be ELF32 since it should target O32).<br>

* Call createMCAsmParser()<br>

* Call a different createMCAsmParser().<o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"><br>

 <br>

Other places that get ABI information wrong:<o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">* AddressSanitizer: Uses Triple::mips64/mips64el to mean the N64 ABI. N32 is a Triple::mips64/mips64el that should behave as the Triple::mips/mipsel cases do.<br>

* DataFlowSanitizer: Is heading down the same road but hasn't implemented O32/N32 yet.<br>

* MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet.<br>

* Many places where hasMips64*() or isGP64bit() are used in the backend.<br>

  * MSA intrinsic lowering<br>

  * Legalization configuration<br>

  * Instruction selection<br>

  * MipsTargetLowering::getOptimalMemOpType()<br>

  * And many more. I can provide more detail if you want.<br>

 <br>

Other notables:<br>

* RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while.<o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"><br>

 <br>

I'll provide a CodeGen example tomorrow if you want.<o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<div>

<div class="MsoNormal" align="center" style="text-align:center"><span style="color:black">

<hr size="2" width="100%" align="center">

</span></div>

<div>

<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"> Eric Christopher [<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>]</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

<div>

<div>

<div>

<div>

<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"><br>

<b>Sent:</b> 23 September 2015 19:49</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

<div>

<div>

<div>

<div>

<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">To:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"> Daniel Sanders; Renato Golin; Jim Grosbach<br>

<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>

<b>Subject:</b> Re: The Trouble with Triples</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

<div>

<div>

<div>

<div>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black"><o:p> </o:p></span></p>

<div>

<div>

<p class="MsoNormal"><span style="color:black">On Wed, Sep 23, 2015 at 11:38 AM Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com" target="_blank">Daniel.Sanders@imgtec.com</a>> wrote:<o:p></o:p></span></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">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">>

</span><span style="color:black">OK, I'm going to just reply to the last because I think it's the most important part of all this and would like to try to have us side tracked again. If you'd like I can reply to it, but let's take the last part first :)<br>

</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">></span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">> > > Could you please provide some examples of things that are impossible right now<br>

> > > with command lines, how those interact with the TargetMachine, and how you see<br>

> > > it being impossible to deal with?<br>

> > There's some examples above but I'll give the detail in the morning. It's 11:30pm<br>

at the moment :-).<br>

> </span><span style="color:black">Let's talk through one of your examples here when you write things up. I think<br>

</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">>

</span><span style="color:black">tracing the execution as you see it will be important to coming to a mutual<br>

</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">>

</span><span style="color:black">understanding here. I know that you have a solution that you see is going to<br>

</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">>

</span><span style="color:black">solve the problems you see, but the I think the problems that you and I are seeing<br>

</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">>

</span><span style="color:black">are possibly not the same thing. So let's walk through this execution trace and see<br>

</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">>

</span><span style="color:black">what we can do.<o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">ABI</span></u><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Let's start at llvm-mc's main(). It's important to note that llvm-mc does not create a TargetMachine.

 Here's a sketch of what happens:</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">So, we can just stop here.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">A couple problems:<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">a) llvm-mc isn't a supported product, but that's not the real issue.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">b) The lack of a TargetMachine at the MC level was something I brought up a long time ago in this thread with my proposed solutions. This is what needs to be fixed, especially given that targets can switch ISA,

 ABI, floating point, etc within a single assemble action.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">I even brought up a lot of these problems originally when I was fixing MIPS to work with the current subtarget rewrite.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black">-eric<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>

</div>

<div>

<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></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">

<div>

<div>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Initialize LLVM</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Parse the command line</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Construct an MCTargetOptions from the flags</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Normalize the triple</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Construct a llvm::Target</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">If the triple is not given, we fetch the default</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">We normalize the triple</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">We call TargetRegistry::lookupTarget() to get a llvm::Target.</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:108.0pt"><span style="font-size:11.0pt;font-family:Wingdings;color:black">�</span><span style="font-size:7.0pt;color:black"> 

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">If –march is given, and Triple::getArchTypeForLLVMName() doesn't return Triple::UnknownArch, the new arch this mutates the triple. Otherwise it applies the –march correctly

 but doesn't change the triple to match. In this way, it's possible to end up with i586-linux-gnu targeting the foobar architecture.</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Call createMCRegInfo()</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Call createMCAsmInfo()</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el)</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should

 permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32.</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">InitMCObjectFileInfo()</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el)</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same problem

 as FDECFEEncoding.</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">createMCInstrInfo()</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">createMCInstPrinter()</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">createMCCodeEmitter()</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">createMCAsmBackend()</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">If emitting assembly, createMCAsmStreamer()</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">if emitting object, createMCObjectStreamer()</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsAsmBackend and ultimately comes from Triple::mips/mipsel vs

 Triple::mips64/mips64el. This is incorrect for N32 (which should be ELF32 but has Triple::mips64/mips64el) and for mips-linux-gnu –mips64 (which should be ELF32 since it should target O32).</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">If assembling createMCAsmParser</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">If disassembling:</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">createMCRegInfo() (again)</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">createMCAsmInfo() (again)</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:108.0pt"><span style="font-size:11.0pt;font-family:Wingdings;color:black">�</span><span style="font-size:7.0pt;color:black"> 

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">This has the same issues as the first call.</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">createMCDisassembler()</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Clang does pretty much the same thing as this but additionally has to deal with using the correct default

 ABI for the given triple. I'll cover this kind of problem in 'CPU Defaults' below.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Other places that get ABI information wrong:</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">AddressSanitizer: Uses Triple::mips64/mips64el to mean the N64 ABI. N32 is a Triple::mips64/mips64el that should behave as the Triple::mips/mipsel cases do.</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">DataFlowSanitizer: Is heading down the same road but hasn't implemented O32/N32 yet.</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet.</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Many places where hasMips64*() or isGP64bit() are used in the backend.</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">MSA intrinsic lowering</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Legalization configuration</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Instruction selection</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">MipsTargetLowering::getOptimalMemOpType()</span><span style="color:black"><o:p></o:p></span></p>

<p style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:"Courier New";color:black">o</span><span style="font-size:7.0pt;color:black">  

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">And many more. I can provide more detail if you want.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Other notables:</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">I'll provide a CodeGen example tomorrow if you want. I'd intended to include one but this email took

 longer to type up than I expected.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Endian Defaults</span></u><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">The toolchain is mips-linux-gnu and targets little endian by default. Here's what currently happens:</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">We parse the triple (mips-linux-gnu) and get Triple::mips</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">No command line flags modify this</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">We construct a TargetMachine and all the other objects using this llvm::Triple.</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">The architecture was Triple::mips so everything configures for big-endian even though the target was supposed to be little endian.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">CPU Defaults</span></u><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">In LLVM, the default CPU is hardcoded to be MIPS32 (in MipsABIInfo::computeTargetABI()). In Clang,

 the default CPU for this triple is hardcoded to be MIPS32R2 (in mips::getMipsCPUAndABI()) and clang always passes an explicit CPU to the backend via –target-cpu.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">On Debian, the default CPU for mipsel-linux-gnu is MIPS-II. On Fedora, the default CPU for mipsel-linux-gnu

 is MIPS32R2. It is not possible to hardcode the default both ways.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">How would you resolve this conflict?</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">In my opinion, the only choices to resolve this conflict are configure-time options or run-time config

 files. Configure-time options to select the default CPU is faster to</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">implement and produces a (slightly) faster clang while run-time config files are more flexible but

 slower to implement and produces a slower clang. To me, configure-time is the</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">sensible short term choice followed by moving to run-time config files once the pressure to achieve

 an initial release is gone.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Now let's consider JIT's. JIT's should default to the host CPU as defined by the host triple so that

 it generates code for the same target as the rest of the system. There is a reasonable argument that the default CPU should be auto-detected CPU for performance reasons but it may not be possible to auto-detect the CPU in all circumstances. We therefore need

 a default to fall back on. This default should be the same as the default for the native compiler on this host (MIPS-II for Debian, MIPS32R2 for Fedora).</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">In my opinion, the default CPU is a property of the target platform since the platform specifies the

 minimum CPU it is intended to run on. Our representation of the target platform is called llvm::Triple so the default CPU belongs in this object. Being in this object means that tools such as clang, or API's such as Target::createTargetMachine() will always

 get the defaults corresponding to the triple. These defaults, as we discussed above vary according to the OS (MIPS-II on Debian, MIPS32R2 on Fedora).</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">This kind of problem also exists in other forms such as Softfloat vs Hardfloat defaults, NAN1985 vs

 NAN2008 defaults, default ABIs, etc.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Other things to mention</span></u><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">MIPS64 is not a fundamentally different architecture from MIPS32. If we had a representation of the

 ABI in the triple then we wouldn't need Triple::mips64/mips64el.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">

 Eric Christopher [mailto:<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>]

<br>

<b>Sent:</b> 23 September 2015 01:34</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

</div>

<div>

<div>

<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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"><br>

<b>To:</b> Daniel Sanders; Renato Golin; Jim Grosbach<br>

<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>

<b>Subject:</b> Re: The Trouble with Triples</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

</div>

<div>

<div>

<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">OK, I'm going to just reply to the last because I think it's the most important part of all this and would like to try to have us side tracked again. If

 you'd like I can reply to it, but let's take the last part first :)<o:p></o:p></span></p>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

<div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">> Could you please provide some examples of things that are impossible right now<br>

> with command lines, how those interact with the TargetMachine, and how you see<br>

> it being impossible to deal with?</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">There's some examples above but I'll give the detail in the morning. It's 11:30pm<br>

at the moment :-).</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Let's talk through one of your examples here when you write things up. I think tracing the execution as you see it will be important to coming to a mutual

 understanding here. I know that you have a solution that you see is going to solve the problems you see, but the I think the problems that you and I are seeing are possibly not the same thing. So let's walk through this execution trace and see what we can

 do.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Thanks!<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">-eric<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<div>

<div class="MsoNormal" align="center" style="text-align:center"><span style="color:black">

<hr size="2" width="100%" align="center">

</span></div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"> Eric

 Christopher [<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>]<br>

<b>Sent:</b> 22 September 2015 20:40<br>

<b>To:</b> Daniel Sanders; Renato Golin; Jim Grosbach<br>

<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a></span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

<div>

<div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"><br>

<b>Subject:</b> Re: The Trouble with Triples</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

<div>

<div>

<div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="color:black"> <o:p></o:p></span></p>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">On Thu, Sep 17, 2015 at 6:21 AM Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com" target="_blank">Daniel.Sanders@imgtec.com</a>> wrote:<o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">I think we need to take a step further back and re-enter from the right starting point. The thing that's

 bothering me about the push back so far is that it's trying to discuss and understand the consequences of resolving the core problem while seemingly ignoring the core problem itself. The reason I've been steering everything back to GNU Triple's being ambiguous

 and inconsistent is because it's the root of all the problems and the fixes to the various issues fall out naturally once this core point has been addressed.</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">*sigh*<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Here's the line of thought that I'd like people to start with:</span><span style="color:black"><o:p></o:p></span></p>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Triples don't describe the target. They look like they should, but they don't. They're really just arbitrary strings.</span><span style="color:black"> <o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Triples are used as a starting point, but no more.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<p><span style="font-size:11.0pt;font-family:Symbol;color:black">�</span><span style="font-size:7.0pt;color:black">        

</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">LLVM relies on Triple as a description of the target. It defines the backend to use, the binary format to use, OS and Vendor specific quirks to enable/disable, the default

 CPU, the default ABI, the endian, and countless other details about the target.</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">These two statements aren't necessarily true in whole.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">a) We don't use the Triple to fully specify the target.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">b) We don't use the Triple to fully specify the ABI.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">c) We don't use the Triple to fully specify the CPU.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">d) We do use the triple to handle endianness since most, if not all, triples actually bother to encode endianness.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">e) The rest of the "countless details" may or may not be relevant, you haven't given an example of what you care about.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">From here on your email relies on all of these assumptions being true. So I'm going to skip past that part and go to where you answer some of my questions.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">At this point, in the MC layer we have a number of classes that need to know the ABI but lack this

 information. Our TargetMachine has an accurate TargetTuple object that describes the invariants of the desired target. The desired ABI is an invariant too so why not have it in the TargetTuple which is already plumbed in everywhere we need it? After all, it's

 a property of the target OS/Environment. If we have the ABI in the TargetTuple, then we don't need any other means to set the ABI, tools can set it up front in the TargetTuple and we don't need any command-line option handling for it in the backend.</span><span style="color:black"><o:p></o:p></span></p>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">This isn't sufficient anyways as I don't want to depend on a weird serialization format to deal with something a simple command line can deal with (or

 you've said this in a way that's confused me). I see you saying you want:<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">-tuple mips-linux-gnu-abio32-el<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">to specify on a command line to, say, llvm-mc or a new assembler interface, or heck, to clang itself, that you want to compile for:<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">-triple mipsel-linux-gnu -mabi=o32<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">right? Basically? (Bikeshedding of how to actually serialize things aside?)<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Meanwhile, in clang we have a number of command line options that change the desired target. Let's

 say we've constructed a Triple and resolved it to TargetTuple (more on that below). We're now processing the –EL option. At the moment, we substitute our mips-linux-gnu triple for a mipsel-linux-gnu triple, construct a Triple object from it and resolve the

 new Triple to a TargetTuple. But why do we need to bother with that kind of weird hackery when we can simply do Obj.setEndian(Little)? This is what Phase 7 of the plan is about. We end up with a cleaner way to process target changes that, until now, have required

 weird triple hacking to handle.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">This is something else I don't understand. Here is the first time you start talking about APIs which is what I'm particularly asking about in my earlier

 mails. I'd like to see how you plan on changing the TargetMachine and MC level APIs to deal with this. It seems like the Tuple is going to be a way to side-load information around to the MC layer and while I agree that something is necessary there, I don't

 think that this solution is the right one. (As I said earlier in the thread)<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">I skipped the Triple -> TargetTuple resolution a moment ago and I should address that now. We already

 know that mapping Triple to TargetTuple is a many to many mapping. One Triple has many possible TargetTuple's depending on the environment. One TargetTuple can be formed from multiple possible Triples. In an ideal world, we'd like to bake in all of these mappings

 so that one clang binary supports everything. Unfortunately, being a many to many mapping, some of these mappings are mutually exclusive. Note that this isn't a new problem resulting from this project. The problem has always been there but has been ignored

 until now. To resolve this, we need to provide configure-time and possibly run-time controls for how this conversion is disambiguated. This resolution is performed as early as possible so that the middle/back-ends don't need to know anything about the ambiguity

 problem.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">The minute you start talking about configure time controls we've already lost. This, for me, is a non-starter. That said, I'd like to see the examples

 you think show that things are impossible to deal with in the current architecture.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">---</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">To reply more directly to your email:</span><span style="color:black"><o:p></o:p></span></p>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Thanks :)<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">>

</span><span style="color:black">What can't be done to TargetMachine to avoid this serialization?<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">TargetMachine already has the serialization (see TargetMachine::TargetTriple). We're not doing anything new here. We're simply replacing one object holding

 faulty information with a new object holding reliable information.<o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">This is side stepping my question and making it about Triple. I've specifically said that TargetMachine does not and is not completely dependent upon Triple.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">> And a followup question: What can't be serialized at the function level in the IR to make certain things clear that aren't global? We already do this

 for a lot of command line options.<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">The data I want to fix is global. I think the bit you may be getting hung up on here is that small

 portions of this global data can also be overridden at the function level. Those overrides aren't a problem and continue to operate in the same way as they do today.</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Examples please.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">> And one more: What global options do we need to consider here?<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">I'm not certain I understand this question. If you're talking command line options, it's things like –EL, -EB, -mips32, -mips32r[2356], -mips64, -mips64r[2356],

 -mabi=…. If you're talking about Triple -> TargetTuple mappings, there's quite a wide variety but the main ones for Mips are endian, architecture, default CPU, and default ABI.<o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">All of these are representable right now in the TargetMachine as far as I can tell. What examples are you having problems with?<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">> The goal of the configuration level of the TargetMachine is that it controls things that don't change at the object level.<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">> This is a fairly recently stated goal, but I think it makes sense for LLVM in general. TargetSubtargetInfo takes care of<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">> everything that resides under this (as much as possible, some bits are still in transition, e.g. TargetOptions). This is part<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">> of my suggestion to Daniel about the problems with MCSubtargetInfo and the assembler. Targets like Mips and ARM<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">> were unfortunately designed to change things on the fly during assembly and need to collate or at least change defaults<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">> as we're processing code. I definitely had to deal with a lot of the pain you're talking about when I was rewriting some<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">> of the handling there during the TargetSubtargetInfo work.<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">I generally agree with this. The key bit I need to draw attention to is that the 'defaults' don't change, but are instead overridden. These constant defaults

 are stored in TargetMachine and particularly TargetMachine::TargetTriple. These defaults are wrong for some toolchains since the information stored in TargetMachine::TargetTriple are wrong. It's the defaults I'm trying to fix rather than the overrides.<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">I don't understand what you mean here.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">I think I understand your proposed plan now and it's a few steps ahead of where we are and where we need to be. I agree that overridable state should be

 in TargetSubtargetInfo, however I can't initialize that state without the default values which come from the faulty information in TargetMachine::TargetTriple. This triple work is a pre-requisite to your plan and at first I don't need to override ABI's.<o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Can you provide an example of using a tool that you're having problems with?<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">> Right now I see TargetTuple as trying to take over all of the various arguments to TargetMachine

 and encapsulate them into a single thing.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">> I also don't see this is bad, but I also don't see it taking all of them right now and I'm not sure

 how it solves some of the existing problems</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">> with data sharing that we've got which is where the push back you're both getting is coming from

 here. Ultimately library-wise I can agree</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">> with some of the directions you're headed - I just don't see the unification and interactions right

 now.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">I think we'll end up with TargetTuple taking over many arguments to TargetMachine but that's not my

 goal at this stage. My goal is simply to fix the faulty information currently held in Triple and use the now-accurate information in TargetTuple to fix various blocking issues that prevent a proper Mips toolchain product based on Clang/LLVM. At the end of

 Phase 7, it become possible to fix a number of issues that are impossible to fix right now because the available data we can consult at the moment is incorrect.</span><span style="color:black"><o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</blockquote>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Could you please provide some examples of things that are impossible right now with command lines, how those interact with the TargetMachine, and how you

 see it being impossible to deal with?<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Thanks<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">-eric<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black"> </span><span style="color:black"><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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">

 Eric Christopher [mailto:<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>]

<br>

<b>Sent:</b> 16 September 2015 23:52<br>

<b>To:</b> Renato Golin; Jim Grosbach<br>

<b>Cc:</b> Daniel Sanders; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">

llvm-dev@lists.llvm.org</a></span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

</div>

<div>

<div>

<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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"><br>

<b>Subject:</b> Re: The Trouble with Triples</span><span style="color:black"><o:p></o:p></span></p>

</div>

</div>

</div>

</div>

</div>

<div>

<div>

<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Let's take a step back here.<o:p></o:p></span></p>

</div>

</div>

</div>

</div>

<div>

<div>

<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">It appears that you and Daniel are trying to solve some problems. I think solving problems is good, I just want to make sure that we're solving them in

 a way that gets us a decent API at the end. I also want to make sure we're solving the right problems.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">TargetTuple appears to be related to the TargetParser as you bring up in this mail. They're two separate parts of similar problems - people trying to both

 serialize command line options and communication from the front end to the backend with respect to target information.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">This leads me to a question: What can't be done to TargetMachine to avoid this serialization?<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">And a followup question: What can't be serialized at the function level in the IR to make certain things clear that aren't global? We already do this for

 a lot of command line options.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">And one more: What global options do we need to consider here?<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">The goal of the configuration level of the TargetMachine is that it controls things that don't change at the object level. This is a fairly recently stated

 goal, but I think it makes sense for LLVM in general. TargetSubtargetInfo takes care of everything that resides under this (as much as possible, some bits are still in transition, e.g. TargetOptions). This is part of my suggestion to Daniel about the problems

 with MCSubtargetInfo and the assembler. Targets like Mips and ARM were unfortunately designed to change things on the fly during assembly and need to collate or at least change defaults as we're processing code. I definitely had to deal with a lot of the pain

 you're talking about when I was rewriting some of the handling there during the TargetSubtargetInfo work.<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Now a bit more on TargetParser + TargetTuple:<o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;color:black">TargetParser appears to be trying to solve the parsing in Triple in a nice way for ARM and also some of the "what kind of subtarget feature

 canonicalization can we do in llvm that makes sense to communicate to the front end". I like this particular idea and have often wanted a library of feature handling, but it seems to have stabilized at an ARM specific set of code with no defined interface.

 I can't even figure out how I'd use it in lib/Basic right now for any target other than ARM. This isn't a condemnation of TargetParser, but I think it's something that needs to be thought through a bit more. It's been hooked up well before I'd expected it

 to and right now if we moved it to the ARM backend from Support it'd make just as much sense as it does where it is now other than making clang depend on the ARM backend as well as the X86 backend :)</span><span style="color:black"><o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;color:black">Right now I see TargetTuple as trying to take over all of the various arguments to TargetMachine and encapsulate them into a single thing.

 I also don't see this is bad, but I also don't see it taking all of them right now and I'm not sure how it solves some of the existing problems with data sharing that we've got which is where the push back you're both getting is coming from here. Ultimately

 library-wise I can agree with some of the directions you're headed - I just don't see the unification and interactions right now.</span><span style="color:black"><o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;color:black">As a suggestion as a way forward here let's see if we can get my questions above answered and also show some of how the interactions between

 llvm's libraries are going to get fixed, moved to a better place, etc here.</span><span style="color:black"><o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;color:black">Thanks!</span><span style="color:black"><o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;color:black">-eric</span><span style="color:black"><o:p></o:p></span></p>

</div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

</div>

</div>

</div>

</div>

</div>

<div>

<div>

<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"> <o:p></o:p></span></p>

<div>

<div>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">On Wed, Sep 16, 2015 at 3:02 PM Renato Golin <<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>> wrote:<o:p></o:p></span></p>

</div>

<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">On 16 September 2015 at 21:56, Jim Grosbach <<a href="mailto:grosbach@apple.com" target="_blank">grosbach@apple.com</a>> wrote:<br>

> Why do we care about GAS? We have an assembler.<br>

<br>

It's not that simple.<br>

<br>

There are a lot of old code out there, including the Linux kernel<br>

which we do care a lot, that only compiles with GAS. We're slowly<br>

moving the legacy code up to modern standards, and specifically some<br>

kernel folks are happy to move up not only the asm syntax, but the C<br>

standard and move away from GNU-specific behaviour. But we're not<br>

quite there yet, and might not be for a few more years. so, yes, we<br>

still care about GAS.<br>

<br>

But this is not just about GAS.<br>

<br>

As I said on my previous email, this is about clearing the bloat in<br>

target descriptions by both: removing the need for adding numerous CPU<br>

names, target features, architecture names (xscale, strongarm, etc),<br>

AND making sure all parties (front/middle/back-ends) speak the same<br>

language, produced from the same source.<br>

<br>

The TargetTuple is that common language, and the TargetParser created<br>

from the TableGen files is the common source. The Triple becomes a<br>

legacy constructor value for the Tuple. All other target information<br>

classes are already (or should be) generated from the TableGen files,<br>

so the ultimate source becomes the TableGen description, which I think<br>

it what you were aiming to on your comment.<br>

<br>

For simple architectures, like x86, you don't even need a<br>

TargetParser. You can easily construct the Tuple from a triple and use<br>

the Tuple as you've always used the triple. No harm done. But for the<br>

complex ones like ARM and MIPS, having a common interface generated<br>

from the same place the other interfaces are is important to avoid<br>

more bridges between front and middle and back end interpretations of<br>

the same target. Whatever legacy ARM or MIPS carry can be isolated in<br>

their own implementation, leaving the rest of the targets with a clean<br>

and simple interface.<br>

<br>

cheers,<br>

--renato<o:p></o:p></span></p>

</blockquote>

</div>

</div>

</div>

</div>

</blockquote>

</div>

</div>

</div>

</div>

</div>

</div>

</blockquote>

</div>

</div>

</div>

</div>

</div>

</div>

</blockquote>

</div>

</div>

</div>

</div>

</div>

</div>

</blockquote>

</div>

</div>

</div>

</div>

</div>

</div>

</blockquote>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</body>

</html>