<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 25, 2016 at 4:08 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span>On Jul 25, 2016, at 4:02 PM, Sean Silva via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<div><blockquote type="cite"><blockquote class="gmail_quote" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I'm sure it is theoretically possible for me to acquire such a system and test on it, but the amount of time and energy it would take make it a practical impossibility.</div><div><br></div><div>Even for fairly pedestrian backends such as AArch64 and PowerPC, we routinely have people ask active developers on those backends to do the triaging of issues. I've never seen this be a problem in practice, and I'm not convinced that it is something we should actually require to have an upstream backend.</div></div></div></blockquote><div style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">As I mentioned in the original thread "[llvm-dev] [RFC] Lanai backend", it seems to me that the "can I run the code coming out of the backend?" property is more about enabling LLVM's users to do interesting things with the backend, rather than about LLVM's internal maintenance.</div><div style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="http://lists.llvm.org/pipermail/llvm-dev/2016-February/095214.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2016-February/095214.html</a><br></div><div style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">I'm not sure how that affects the decision.</div></blockquote><br></div></span><div>MHO, but I almost completely disagree with you.  I agree that the question comes down to asking how much benefit to the community there is to merging the backend, balances vs how much cost there is (your "internal maintenance" point).</div></div></blockquote><div><br></div><div>Was there supposed to be a sentence here explaining what you specifically disagree with? I'm having a hard time understanding what it is you disagree with. AFAICT, in the post you quoted and the linked post, I made only two statements that you might disagree with:</div><div>1. <span style="font-family:helvetica;font-size:12px">"can I run the code coming out of the backend?" property is more about enabling LLVM's users to do interesting things with the backend, rather than about LLVM's internal maintenance.</span></div><div><span style="font-family:helvetica;font-size:12px">2. </span><font face="helvetica"><span style="font-size:12px">As far as maintenance of the LLVM </span></font><span style="font-size:12px;font-family:helvetica">project is concerned, leaning on active maintainers is the way that issues </span><span style="font-size:12px;font-family:helvetica">get solved in practice, so the "can I run the code" quality isn't relevant </span><span style="font-size:12px;font-family:helvetica">for maintenance.</span></div><div><span style="font-size:12px;font-family:helvetica"><br></span></div><div><span style="font-size:12px;font-family:helvetica">Which one is it? (or was there something else I said in this thread or the linked thread that you were referring to?)</span></div><div><span style="font-size:12px;font-family:helvetica">FWIW, I don't disagree with any of the points you brought up.</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div>It is unquestionably easier for a contributor to land their backend in-tree than to maintain it out-of-tree.  This is because landing it in tree shifts the maintenance burden from the *contributor* to the *community*.  If there is low value to the community, then this is a "bad deal” for the project as a whole, since there is only so much attention to go around.</div><span><div><br></div><div><blockquote type="cite"><div>My gut (and I'm actually not sure if I exactly consider this a pro or a con personally) is that is sounds Stallman-esque to require backends to answer "yes" to "can I run the code coming out of the backend?". If you squint it is sort of like an anti-tivoization requirement, which would be a very ironic requirement for a BSD-licensed project.</div></blockquote><br></div></span><div>This seems like some weird FUD or mud slinging argument, I’m not sure what to make of it.</div></div></blockquote><div><br></div><div>If I understand what you're saying correctly, you don't see the parallel with tivoization?</div><div><br></div><div>Essentially, both anti-tivoization and requiring that one can run the code that comes out of an LLVM backend involve a situation where a programmer has access to code (either the GPL code in the anti-tivoization case, or LLVM source code in the LLVM backend case) and is free to modify it how ever they want. However, without the extra requirement (either anti-tivoization clause or requiring the ability to run the code that comes from an LLVM backend), hardware manufacturers would be able to restrict that programmer's ability to use their modified code for its intended purpose (either powering the tivo device or compiling code that is then run on the device targeted by the LLVM backend).</div><div><br></div><div>Hopefully that makes sense. I'm not trying to spread FUD or sling mud or make an argument, but rather to draw a parallel.</div><div><br></div><div>A lot of us are hacker/tinkerers at heart, and so there is some attractiveness to knowing that if we (or others like us) are interested, we can go and play around with a backend, learn about the ISA, compile some code, and run stuff. I've personally done this e.g. for AMDGPU at home, purely out of curiosity (I purchased a machine with an AMD GPU specifically for this purpose). I think this resonates with quite a few in the community (or maybe it is just me :) [1]). So on the surface it seems like this might be an interesting consideration. However, I think those people have converged on putting aside these feelings and seeing that for the project as a whole, it is not the right thing to look at; and also that there are existing examples like SystemZ that show that really we didn't feel so strongly about it after all.</div><div><br></div><div>Now, from what I gather from the other thread, your incoming concern is different, given your different set of experiences:</div><div>"Maybe I just carry too many scars here. Remember that I was the guy who got stuck with rewriting the "new” SPARC port from scratch, because otherwise we “couldn’t” remove the (barely working) “SparcV9" backend, which was dependent on a bunch of obsolete infrastructure.  I didn’t even have a Sparc machine to test on, so I had to SSH into remote machines I got access to."</div><div>That's fine, but not everybody is coming into the discussion from that background.</div><div>Although, notice that your experiences gave you quite a head start over many of us -- it seems that at this point we all have come to agree that the internal concerns of LLVM maintenance are the common consideration, as you insisted from the start.</div><div><br></div><div>[1] Although the Apple mobile GPU example has consistently convinced me that "can I run the code" should not play a role in accepting a backend.</div><div><br></div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span><font color="#888888"><div><br></div><div>-Chris</div></font></span></div></blockquote></div><br></div></div>