<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 2:37 PM, Chris Lattner via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> On Feb 9, 2016, at 9:40 AM, Jacques Pienaar via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> We would like to contribute a new backend for the Lanai processor (derived from the processor described in [1]).<br>
<br>
</span>Hi Jacques,<br>
<br>
We generally have a low bar for accepting new “experimental” backends, but I think that this is the first proposal to add a target for a hardware that general LLVM contributors can’t have access to. As such, we’ll have to figure out as a community whether this makes sense.<br>
<br>
Here are the tradeoffs I see of accepting the backend:<br>
<br>
1) I imagine that there is a big win for you, not having to merge with mainline. Maintaining an out of tree backend is a pain :-)<br>
<br>
2) For the community, this is probably a net loss since changes to common codegen could would be required to update your backend, but no one else in the community would benefit from the target being in mainline.<br>
<br>
3) There is probably a small but non-zero benefit to keeping your team working directly on mainline, since you’re more likely to do ancillary work in ToT. If your development is in mainline, this work is most likely to go into <a href="http://llvm.org" rel="noreferrer" target="_blank">llvm.org</a> instead of into your local branch.<br>
<br>
4) There could be an educational benefit of having the backend, particularly if it has unique challenges to overcome.<br>
<br>
<br>
What do others think about this? I know that several organizations have not even bothered proposing internal-only targets for inclusion in <a href="http://llvm.org" rel="noreferrer" target="_blank">llvm.org</a>, since they would effectively be contributing dead code that the community would have to maintain.<br></blockquote><div><br></div><div>One data point (IIRC) is that the NVPTX backend sat in tree for a long time without a way to actually use them. But lately this has been opening up (e.g. <a href="http://llvm.org/docs/CompileCudaWithLLVM.html">http://llvm.org/docs/CompileCudaWithLLVM.html</a>). However, the obstacle for NVPTX was mostly a software proprietary-ness (no way to plug it into the driver stack really, except via nvidia's own proprietary software), whereas the actual hardware was available. For the Lanai stuff, it seems like the hardware is fundamentally not available for purchase.</div><div><br></div><div>The reverse situation is with e.g. Apple's GPU backends, where the devices are readily available, but (AFAIK) even if the backend were open-source you couldn't run the code produced by the open-source compiler.</div><div><br></div><div>Or to put it in matrix form (this is all heavily prefixed by "AFAIK"; corrections welcome):</div><div><br></div><div><font face="monospace, monospace">AMDGPU: InTree:Yes DevicesAvailable:Yes CanIRunTheCode:Yes</font></div><div><font face="monospace, monospace">NVPTX: InTree:Yes DevicesAvailable:Yes </font><span style="font-family:monospace,monospace">CanIRunTheCode</span><font face="monospace, monospace">:Yes</font></div><div><font face="monospace, monospace">Lanai: InTree:? DevicesAvailable:No </font><span style="font-family:monospace,monospace">CanIRunTheCode</span><font face="monospace, monospace">:No</font></div><div><font face="monospace, monospace">Apple GPU's: InTree:No DevicesAvailable:Yes </font><span style="font-family:monospace,monospace">CanIRunTheCode</span><font face="monospace, monospace">:No</font></div><div> </div><div>I couldn't come up with a good name for "Can I Run The Code" column. Basically it means: "assuming the backend were in open source, could I actually run the code produced by the open source backend somehow?".</div><div><br></div><div>I had a quick look at lib/Target and it seems like every backend we have has "CanIRunTheCode:Yes" in theory.</div><div>IIRC, the NVPTX stuff used to actually be "No" though?</div><div><br></div><div>Anyway, just a random thought. Not sure what the conclusion is.</div><div><br></div><div>-- Sean Silva</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
-Chris<br>
<div class=""><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>