<div dir="ltr"><div><span style="font-size:12.8px">From Simon's email:</span></div><div><span style="font-size:12.8px">> I've forwarded this message onto Daniel as he is no longer with Imagination</span><br></div><span style="font-size:12.8px">> Technologies.</span><br><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thanks.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">From Renato's email:</span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">In the GNU world, the triple is mostly descriptive, and the build-time</span><br style="font-size:12.8px"><span style="font-size:12.8px">> </span><span style="font-size:12.8px">configure options are what really define behaviour. So each</span><br style="font-size:12.8px"><span style="font-size:12.8px">> </span><span style="font-size:12.8px">distribution (of Linux, Mac, BSD) has done their own ways. Most of the</span><br style="font-size:12.8px"><span style="font-size:12.8px">> </span><span style="font-size:12.8px">time, they have also chosen their own "different" triples, but not</span><br style="font-size:12.8px"><span style="font-size:12.8px">> </span><span style="font-size:12.8px">always.</span><br style="font-size:12.8px"></div><div><span style="font-size:12.8px">></span></div><div><span style="font-size:12.8px">> In the LLVM world, we don't have build-time options, so *all* logic</span><br style="font-size:12.8px"><span style="font-size:12.8px">> </span><span style="font-size:12.8px">has to be in triples and command line options. Most of the time that</span><br style="font-size:12.8px"><span style="font-size:12.8px">> </span><span style="font-size:12.8px">works because the triples are all slightly different, but they're not</span><br style="font-size:12.8px"><span style="font-size:12.8px">> </span><span style="font-size:12.8px">always, and sometimes we either get things wrong, or we can't</span><br style="font-size:12.8px"><span style="font-size:12.8px">> </span><span style="font-size:12.8px">represent something that GCC can with build-time options.</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The new Debian mips64el port hit this problem recently and is currently carrying a small patch to change a default for their triple. I was planning to suggest something that would bring such patches upstream but I decided to wait until my latest set of triple patches were upstream before adding another element to an already complicated problem.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The gist of that plan is to attach such distribution specific behaviour to vendored triples and allow distributions to map their distribution triple to their preferred vendored triple in LLVM. The overall effect is that distributions get the ability to control the defaults of their native compilers like they do for gcc but LLVM's ability to cross-compile to anything is preserved.<br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 22, 2016 at 4:01 PM, Simon Dardis <span dir="ltr"><<a href="mailto:Simon.Dardis@imgtec.com" target="_blank">Simon.Dardis@imgtec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> -----Original Message-----<br>
> From: cfe-dev [mailto:<a href="mailto:cfe-dev-bounces@lists.llvm.org">cfe-dev-bounces@lists.<wbr>llvm.org</a>] On Behalf Of Renato<br>
> Golin via cfe-dev<br>
> Sent: 22 August 2016 13:55<br>
> To: Sam Parker<br>
> Cc: Daniel Sanders; nd; <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> Subject: Re: [cfe-dev] ARM procedure calls (sorry)<br>
><br>
</span><span class="">> On 22 August 2016 at 13:13, Sam Parker <<a href="mailto:Sam.Parker@arm.com">Sam.Parker@arm.com</a>> wrote:<br>
> > Well the code I was looking at was making assumptions about what the<br>
> > backend will decide about procedure calls, so why not ask the backend?<br>
><br>
> Exposing back-end information to the front-end is a pandora's box. You can<br>
> start naive and only ask what you really need to know, and then people will<br>
> be using for all sorts of little quirks and suddenly the IR generated by Clang<br>
> will be in a tight contract with what each LLVM back-end can consume (aka.<br>
> high coupling).<br>
><br>
> The way we do today, for better or worse, is to have the Triple class expose<br>
> all information front-ends need to know. This is far from perfect, but if you<br>
> want to make that relationship more coese, I suggest you look into the Triple<br>
> class.<br>
><br>
> One of the recent efforts by Daniel Sanders to re-factor the Triple class was a<br>
> way to fix that madness in the Mips back-end, which is somewhat similar to<br>
> ARM's. If you want to look into that, I suggest you contact Daniel and Eric<br>
> (CC's), as there was a lot of discussions around design and behaviour.<br>
<br>
</span>Yes, Daniel developed a series of patches that brought the Mips backend into<br>
line with some of the other targets by modifying the triple for Mips to carry<br>
ABI information. (I will taking over that patch series).<br>
<br>
Our goal there was to be able to distinguish at the relevant places what ABI<br>
was in use, as certain targets have the same triple but different ABI.<br>
<br>
I've forwarded this message onto Daniel as he is no longer with Imagination<br>
Technologies.<br>
<br>
Thanks,<br>
Simon<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> > I haven't looked at the target classes in Clang in a long time, but<br>
> > just having a quick look now there still appears to be duplication<br>
> > with LLVM's target machine and subtargets, at least for ARM anyway.<br>
><br>
> Most of the target knowledge in Clang uses the Triple already, and they're<br>
> mostly concerning themselves with front-end stuff, which is what we want.<br>
> The meaning of triples and flags play a different part in all this...<br>
><br>
><br>
> > For instance, the triple is<br>
> > used for ABI and data layout calculations and there's no end of flags<br>
> > for features. I guess I must be missing something, but it just seems<br>
> > odd and harder to maintain having two descriptions of the targets.<br>
><br>
> This is, unfortunately, a *requirement*. And a bad one at that.<br>
><br>
> In the GNU world, the triple is mostly descriptive, and the build-time<br>
> configure options are what really define behaviour. So each distribution (of<br>
> Linux, Mac, BSD) has done their own ways. Most of the time, they have also<br>
> chosen their own "different" triples, but not always.<br>
><br>
> In the LLVM world, we don't have build-time options, so *all* logic has to be<br>
> in triples and command line options. Most of the time that works because<br>
> the triples are all slightly different, but they're not always, and sometimes we<br>
> either get things wrong, or we can't represent something that GCC can with<br>
> build-time options.<br>
><br>
> Using target options won't help, since the target class doesn't know which<br>
> system it's running and which ABI is should default to or fall back to, etc. So, if<br>
> we keep all that logic in the Triple, which is an LLVM class and *has* access to<br>
> the target information, we *can* perform a proxy pattern from the real<br>
> target information to the front-ends without perverting the encapsulation.<br>
><br>
> Maybe, the simplest way to fix this mess is to enhance the Triple class to<br>
> have more target knowledge, so we can make sure that whatever Clang<br>
> interprets as "arm-none-eabi" is the exact same thing the back-end will<br>
> when it sees it in the IR.<br>
><br>
> We're probably pretty close, even it mostly by accident. However, making it<br>
> clearer won't be a bad move.<br>
><br>
> cheers,<br>
> --renato<br>
> ______________________________<wbr>_________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>