<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:x="urn:schemas-microsoft-com:office:excel" 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=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Courier New";
mso-fareast-language:EN-US;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
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";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
mso-fareast-language:EN-GB;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Courier New";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Eric Christopher
<a href="mailto:echristo@gmail.com">echristo@gmail.com</a> writes:<br>
</span>> Long time no hear :)<br>
<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.<br>
<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><o:p></o:p></p>
<p class="MsoNormal">> Right now this isn't completely possible.<o:p></o:p></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.<o:p></o:p></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 :)<o:p></o:p></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:#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.)<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:#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.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Daniel Sanders <a href="mailto:Daniel.Sanders@imgtec.com">
Daniel.Sanders@imgtec.com</a> writes:<o:p></o:p></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.<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:#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.<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:#1F497D">Matthew<o:p></o:p></span></p>
</div>
</body>
</html>