<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 23, 2015 at 3:26 PM 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><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">> >
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
</span>As I understand it your proposal aims to help solve the issue of getting the complete<br>
> > set of ABI information to every part of LLVM that needs it and you are saying<br>
> > TargetMachine should encapsulate that data directly.
</div></div><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote"><div>> Essentially. To be more precise I'm saying that TargetMachine (or an MC level equivalent<br>
> - see TargetSubtargetInfo/MCSubtargetInfo) should encapsulate everything that's needed<br>
> from the object level down for any particular target. <br>
<br></div></div></div></div></div></div></div></div><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote"><div>
That sounds like TargetTuple but spelt something like MCTargetMachine. It sounds like MCTargetMachine should usurp the Triple in the places it exists in the MC layer (and maybe be introduced to a few new portions of it) and accurately reflect the desired target
 just like in the later stages of the TargetTuple plan intended. The main difference I see is small a small subset of the fields can be removed because they aren't needed in the MC layer and we may end up with more than one TargetTuple-like object (one for
 each major aspect of LLVM).<br></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Right. So I agree with some of this and not with others.</div><div><br></div><div>a) Right now we have an is-a relationship between TargetSubtargetInfo and MCSubtargetInfo as I mentioned in an earlier mail. I really really don't like it, but changing it out is complicated. I think it'll be interesting to see how this goes with MCTargetMachine.</div><div><br></div><div>b) I don't necessarily think it should usurp the Triple in the MC layer, but rather perform as an extra layer between MCSubtargetInfo and the rest of the assembler interface.</div><div><br></div><div>c) I think we'll only want one MCTargetMachine for any invocation of clang/llvm-mc/etc. It should be able to mode switch (via MCSubtargetInfos possibly?) when necessary (e.g. .set mips3) similar to how TargetMachine does at the IR level.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote"><div>
<br>
I'm wondering if this point has been one big communication failure.<br>
</div>
<div lang="EN-GB"></div></div></div></div></div></div></div></div><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote"><div lang="EN-GB"> </div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I think so? :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote"><div lang="EN-GB"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><br>
> > My perspective on ‘the trouble with triples’:</span>
</div></div></div></div></div></div></div></div><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote"><div lang="EN-GB"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> >
</span>Given you have a GNU background I’ll pose a scenario in GCC config parlance and perhaps you</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> >
</span>can explain how, if at all, you see LLVM responding to the issue. This is a fake scenario but is still</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> >
</span>representative of what happens in the real world.</span></p>
</div></div></div></div></div></div></div></div></div><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote"><div lang="EN-GB"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> </span></span></span><snip></p>
</div>
</div></div></div></div></div></div></div></div><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote">
<div><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>
</span></span>Right now this isn't completely possible. I agree that it should be and I personally imagine this as being done via toolchain<br>
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>
</span></span>configuring to set defaults at the clang level. We already do some of this for target, I just see it adding more to that sort<br>
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>
</span></span>of configuration (whether or not done via autoconf is completely orthogonal of course :)</div>
<br></div></div></div></div></div></div></div><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote">
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.<br></div></div></div></div></div></div></div></blockquote><div><br></div><div>JIT users already have to construct the TargetMachine. As do debugger users. A JIT user should be configuring as they'd like to execute things without (possibly) taking into account what the surrounding binary is doing (as you can have interprocess jitting anyhow). A debugger should, theoretically at least, be using the ELF flags of the target binary. If something can't be represented there we'll generally use a section of flags if I recall what we did with gcc when we needed to pass extraneous data around.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote">
<div></div></div></div></div></div></div></div></div><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote"><div><br>
> b) The lack of a TargetMachine at the MC level was something I brought up a long time ago in<br>
> this thread with my proposed solutions. This is what needs to be fixed, especially given that targets<br>
> can switch ISA, ABI, floating point, etc within a single assemble action.<br>
<br></div></div></div></div></div></div></div></div><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr"><div><div class="gmail_quote"><div>
This is somewhat off-topic but just for my own knowledge. When you say 'ABI' here do you mean the register names or the wider ABI? I'm aware we can change register names but I don't think we can change the actual ABI on the fly.<br></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Wider ABI, i.e. something like .set fpmath= could change the ABI for surrounding functions. I'm... disappointed at how that works in the ELF flags case, but it might be less of an issue.</div><div><br></div><div>-eric </div></div></div>