<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 23, 2015 at 3:38 PM Matthew Fortune <<a href="mailto:Matthew.Fortune@imgtec.com">Matthew.Fortune@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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Eric Christopher
<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a> writes:<br>
</span>> Long time no hear :)<br>
</p></div></div><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><br>
Indeed. I try to keep quiet as I have a nasty tendency to get involved in too many things.</span></p></div></div><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><br></span></p></div></div></blockquote><div><br></div><div>*looks at how many email threads he's in*</div><div><br></div><div>Yep. Totally understand :)</div><div> </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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
<br>
>> If I want to use clang as simply as I use GCC what do I need to change in llvm/clang to create a compiler such that I can replace ‘gcc’ above with ‘clang’ and get the same effect?</span></p></div></div><div lang="EN-GB" link="blue" vlink="purple"><div>
<p class="MsoNormal">> Right now this isn't completely possible.<u></u><u></u></p>
<p class="MsoNormal">> I agree that it should be and I personally imagine this as being done via toolchain configuring to set defaults at the clang level.<u></u><u></u></p>
<p class="MsoNormal">> We already do some of this for target, I just see it adding more to that sort of configuration (whether or not done via autoconf is completely orthogonal of course :)<u></u><u></u></p>
</div></div><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I wouldn’t impose autoconf on anyone who has escaped it. As long as we have a route to push this
 information into a build that is fine. Several CMAKE variables would do the same thing. That change seems like a no-brainer and could potentially be done in parallel to fixing how the information then goes on to flow through LLVM. (If autoconf based builds
 are still alive in LLVM I could try and coach someone through how to do this in autoconf but if it is dying in LLVM then let’s not feed it.)</span></p></div></div></blockquote><div>I can also coach them through. But yes, this is exactly what should happen. <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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The only other part of this is to deal with the concept of the vendor triple which I assume there
 would be no objection to having these essentially do what the CMAKE controls would do and update the TargetMachine to set up the right defaults. I’d hope all this eventually means the ‘triple’ object would become mostly unused except as a method of initialising
 the more detailed information in the target machine and when it is needed because it appears in a path. Whatever uses triple today would then consult individual pieces of information in the TargetMachine instead. (As before I don’t think we need dwell on this
 here though but instead begin discussion about enhancing TargetMachine to start with and then inventing MCTargetMachine.)</span></p></div></div></blockquote><div><br></div><div>Yep. My baseline is "canonicalize the triple as much as you can coming in, it'll save you some parsing later, otherwise just query the TargetMachine".</div><div> </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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p></div></div><div lang="EN-GB" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="color:black">Daniel Sanders <a href="mailto:Daniel.Sanders@imgtec.com" target="_blank">
Daniel.Sanders@imgtec.com</a> writes:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black">The question I want to ask here is: What about API users? Things like JIT's and debuggers will want the same defaults (possibly augmented by auto-detection). One nice thing about handling this in the Triple/TargetTuple
 boundary was that these users get the same behaviour as clang in all areas of LLVM.<u></u><u></u></span></p>
</div></div><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Only the compiler driver is impacted by customised meanings of triples. It is a JIT’s responsibility
 to know what it is targeting and if that needs to match the host compiler then that information needs to be extracted from the pre-processor breadcrumbs available when compiling the JIT driver itself which describe the options the JIT driver is being built
 with; these then have to be translated into TargetMachine settings. A JIT won’t know what triple to use let alone the other data without taking it from its own build environment. For disassemblers a similar story applies the information needs to be taken from
 the ELF though this time and anything missing is a failing of the MIPS ELF format which would need extending to carry the information. .MIPS.abiflags helps massively here though.</span></p></div></div></blockquote><div><br></div><div>Yep. :)</div><div><br></div><div>-eric</div><div> </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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p></div></div><div lang="EN-GB" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Matthew<u></u><u></u></span></p>
</div></div></blockquote></div></div>