<div dir="ltr">Hi Daniel,<div><br></div><div>I'm not sure I agree with the basic idea of using the target triple as a way of encoding all of the pieces of target data as a string. I think in a number of cases what we need to do is either open up API to the back end to specify things, or encode the information into the IR when it's different from the generic triple. Ideally the triple will have enough information to do basic layout and anything else can be either gotten from the IR or passed via option.</div><div><br></div><div>My suggestion on a route forward here is that we should look at the particular API and areas of the backend that you're having an issue with and figure out how to best communicate the data you'd like to the appropriate area. I realize this probably seems a little vague and handwavy, but I don't know what areas you've been having problems with lately. I'll absolutely help with this effort if you need assistance or guidance in any way.</div><div><br></div><div>Thanks!</div><div><br></div><div>-eric<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 8, 2015 at 7:31 AM Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com">Daniel.Sanders@imgtec.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Hi,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">In <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10969&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=SQ1GVuhHgotIRf4skqeojoXI6YpHx5yItEUNbw6OWjo&s=5IyRsNqsZt3tTpIG1XLQQDBdaio57SHjU-_anMpXBLI&e=" target="_blank">http://reviews.llvm.org/D10969</a>, Eric asked me to explain the wider context of the TargetTuple object that was replacing Triple on llvmdev so here it is.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Before I start, I'm sure I don't know the full extent of GNU triple ambiguity and lack of canonicity. Additional examples are welcome.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u>The Problem</u><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">As you know, LLVM uses a GNU Triple is as a target description that can be relied upon to make decisions. It's used for various decisions such as the default cpu, the alignment of types, the object format, the names for libcalls, and a
wide variety of others.<u></u><u></u></p>
<p class="MsoNormal">In using it like this, LLVM assumes that triples are unambiguous and have a specific defined meaning. Unfortunately, this assumption fails for a number of reasons.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The first reason is that compiler options can overrule the triple but leave it unchanged. For example, in GCC mips-linux-gnu-gcc normally produces 32-bit MIPS-I output using the O32 ABI, but 'mips-linux-gnu-gcc –mips64' normally produces
64-bit MIPS-III output using the N32 ABI. Like GCC, compiler options to mips-linux-gnu-clang should (and mostly do but MIPS has a few crashing cases caused by triple misuse) overrule the triple. However, we don't mutate the triple to reflect this so any decisions
based on the overridable state cannot rely on the triple to accurately reflect the desired behaviour.<u></u><u></u></p>
<p class="MsoNormal">It's worth mentioning here that some targets have hacks to partially mutate the triple in clang to work around issues they would otherwise have in the backend but this is done on an ad-hoc basis for specific details (e.g. mips <-> mipsel
for –EL and -EB).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The second reason is that there is no canonical meaning for a given GNU Triple, it varies between vendors and over time. There is also no requirement for vendors to have a unique GNU Triple for their toolchain. For GCC, it's fairly common
for distributors to change the meanings of triples using options like --with-arch, --with-cpu, --with-abi, etc. There are also some target-specific options such as --with-mode to select ARM/Thumb by default and --with-nan for MIPS NAN encoding selection. Different
vendors use different configure options and may change them at will. When they do change them, the vendors often desire to keep the same triple to be able to drop in the new version without causing wider impact on their environment. For example, assuming I'm
reading debian/rules2 for Debian's gcc-4.9 package correctly then the i386-linux-gnu means i486 on Debian Etch and Lenny but means i586 on more recent versions. On a similar note, on Debian, mips-linux-gnu targets MIPS-II (optimised for typical MIPS32 implementations)
rather than the usual MIPS-I. The last example of this ambiguity I'd like to reference is that mentioned by
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.debian.org_Multiarch_Tuples-23Why-5Fnot-5Fuse-5FGNU-5Ftriplets.3F&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=SQ1GVuhHgotIRf4skqeojoXI6YpHx5yItEUNbw6OWjo&s=qThy69Gf7YPsGrdABKZzzYkM1ojhZNmvZszbzDc_V8g&e=" target="_blank">https://wiki.debian.org/Multiarch/Tuples#Why_not_use_GNU_triplets.3F</a>. In that example, hard-float and soft-float on ARM both used arm-linux-gnueabi but were mutually incompatible.
The Multiarch tuples described on that page are an attempt to resolve the ambiguity but I'm told that they aren't likely to be universally adopted.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The third reason, is that different triples can mean the same thing. Jim Grosbach has mentioned that the prefixes of the GNU Triple are different between Linux and Darwin for ARM despite sharing the same meaning (presumably subject to the
issues above). As a result decisions based on the string have to take care of multiple possible values. Mips has a similar issue too since a host triple (and therefore default target triple) of mips64-linux-gnu needs to behave like mips-linux-gnu on a 32-bit
Mips port of Debian.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Although not included in the description of the assumption above, one additional flaw in the use of GNU Triples is that they are sometimes inadequate as a description of the target. One example affecting MIPS in particular is that the ABI
is not represented in the GNU Triple we require significant API changes to get this information where we need it. It would be helpful to be able to pass such information through the existing plumbing.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u>The Planned Solution<u></u><u></u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The plan is to split the GNU Triple represented by the llvm::Triple object into two pieces. The first piece is the existing llvm::Triple and is responsible for parsing the GNU triple and canonicalizing it. The second piece is a mutable
target description named llvm::TargetTuple. TargetTuple is responsible for interpreting the triple according to the vendor's rules, providing an interface to allow mutation by tools, and authoritatively defining the target being targeted without the ambiguity
of GNU Triples. As an example, 'mips-linux-gnu-clang –EL …' would:<u></u><u></u></p>
<p class="MsoNormal" style="text-indent:18.0pt"><span style="font-family:"Courier New"">// Parse the GNU Triple
<u></u><u></u></span></p>
<p class="MsoNormal" style="text-indent:18.0pt"><span style="font-family:"Courier New"">llvm::Triple GnuTriple("mips-linux-gnu");<u></u><u></u></span></p>
<p class="MsoNormal" style="text-indent:18.0pt"><span style="font-family:"Courier New"">// Convert it to a TargetTuple according to the (possibly customized) meanings in<u></u><u></u></span></p>
<p class="MsoNormal" style="text-indent:18.0pt"><span style="font-family:"Courier New"">// use by the vendor.<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:18.0pt"><span style="font-family:"Courier New"">llvm::TargetTuple TT(GnuTriple);
<br>
// Then mutate the TargetTuple according to the compiler options (or equivalent depending<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:18.0pt"><span style="font-family:"Courier New"">// on the tool, for example disassemblers would mutate it according to the object headers).<br>
if (hasOption("-EL"))<br>
TT.setLittleEndian()<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:18.0pt"><span style="font-family:"Courier New"">...<u></u><u></u></span></p>
<p class="MsoNormal">At this point, TT would be "+mipsel-unknown-linux-gnu-elf32-some-other-stuff" (exact serialization is t.b.d and may end up target dependent) which we can then rely on in the rest of LLVM. This split resolves the issue of llvm::Triple objects
not being reliable when used as a target description since TargetTuple will reflect the result of interpreting the triple as well as applying appropriate options. It also provides a suitable place for vendors to define the meanings of their GNU Triples.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">One significant detail is the way vendors customize the meaning of their Triples. Currently, the plan is to nominate a constructor (TargetTuple::TargetTuple(const Triple &)) a vendor can patch to redefine their triples with the default
implementation being the 'usual' meaning (the meaning that should be used in the absence of customization). One nice benefit of this configure-by-source-patch approach is that vendors can customize multiple triples as easily as their native triple or intended
target triple. To use Debian as an example again, they would be able to customize all their supported triples such that 'clang –target arm-linux-gnueabihf' on the amd64 port targets their armhf port using the same customization that makes 'clang' on the armhf
port do the right thing natively. Android, and toolchains for heterogenous platform would likely benefit from this too. This configure-by-source-patch approach seems to make some people uncomfortable so we may have to find another way to configure the triples
(tablegen?).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">To reach this result the plan is to do the following:<u></u><u></u></p>
<p><u></u><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Replace any remaining std::string's and StringRef's containing GNU triples with Triple objects.<u></u><u></u></p>
<p><u></u><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Split the llvm::Triple class into llvm::Triple and llvm::TargetTuple classes. Both are identical in implementation and almost identical in interface at this stage.<u></u><u></u></p>
<p><u></u><span>3.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Gradually replace Triples with TargetTuples until the C APIs and the LLVM-IR are the only place inside LLVM where Triples are still used.<u></u><u></u></p>
<p><u></u><span>4.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Change the implementation of TargetTuple to whatever is convenient for LLVM's internals and decide on a serialization.<u></u><u></u></p>
<p><u></u><span>5.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Replace serialized Triples with serialized TargetTuples in LLVM-IR.<u></u><u></u></p>
<p style="margin-left:72.0pt">
<u></u><span>a.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Maintain backwards compatibility with IR using triples, at least for a while.<u></u><u></u></p>
<p><u></u><span>6.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Add TargetTuple support to the C API. Exact API is t.b.d.<u></u><u></u></p>
<p><u></u><span>7.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Have the API users mutate the TargetTuple appropriately.<u></u><u></u></p>
<p class="MsoNormal">Renato: This has been revised slightly from the last one we discussed due to public C++ API's being used internally as well as externally.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u>Where we are now<u></u><u></u></u></p>
<p class="MsoNormal"><u><u></u><span style="text-decoration:none"> </span><u></u></u></p>
<p class="MsoNormal">I've just started posting patches for step 2 and 3 of the plan. My working copy is nearly at step 4.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u>What's next<u></u><u></u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Upstream step 2 and 3 and then begin replacing the TargetTuple implementation as per step 4.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u>Previous Discussions<u></u><u></u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__thread.gmane.org_gmane.comp.compilers.llvm.devel_86020_focus-3D86073&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=SQ1GVuhHgotIRf4skqeojoXI6YpHx5yItEUNbw6OWjo&s=HBroMZHO2pao7guZ9z8tK8Fx_zpL3f1dqj1dDRfRXOM&e=" target="_blank">http://thread.gmane.org/gmane.comp.compilers.llvm.devel/86020/focus=86073</a>. I should mention that I've since been made aware that the original topic
of private label prefixes could be solved in a much simpler way than previously thought. The triple related discussion is still relevant though.<u></u><u></u></p>
<p class="MsoNormal">I understand from Renato that there are more threads over the last few years but I haven't looked for them.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="text-align:justify"><b><span style="font-size:12.0pt;font-family:"Arial","sans-serif";color:#3333ff">Daniel Sanders<u></u><u></u></span></b></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#3333ff">Leading Software Design Engineer, MIPS Processor IP<u></u><u></u></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#3333ff">Imagination Technologies Limited<u></u><u></u></span></p>
<p class="MsoNormal" style="text-align:justify"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.imgtec.com_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=SQ1GVuhHgotIRf4skqeojoXI6YpHx5yItEUNbw6OWjo&s=4zfbTl48xPgmj8iAcBDtLhgRtq8seF-natg6xRFU7vo&e=" target="_blank"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:blue">www.imgtec.com</span></a><span style="font-size:10.0pt;font-family:"Arial","sans-serif""><u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</blockquote></div></div></div>