<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 3:40 AM, Renato Golin 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">On 10 February 2016 at 06:44, Chandler Carruth via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> But I also see another option, which someone else mentioned up-thread:<br>
> simply make only the regression tests be supported. Without a regression<br>
> test case that exhibits a bug, no reverts or other complaints. It would be<br>
> entirely up to the maintainer to find and reduce such test cases from any<br>
> failure of execution tests out-of-tree.<br>
<br>
</span>IMHO, it's about transparency and commitment.<br>
<br>
For experimental back-ends (like BPF), what you describe is perfectly<br>
fine. If we wanted BPF to be official, I'd personally only accept it<br>
if there was at least one buildbot with a minimal domain-specific set<br>
of tests.</blockquote><div><br></div><div>Why would that be a requirement for you?</div><div> </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"> In the BPF case, I'd expect a Linux booting and running some<br>
arbitrary code expecting a certain result. In a hardware-simile, like<br>
your back-end, I'd expect some generic code to be compiled and run<br>
successfully, strongly biased to getting the test-suite running on it.<br>
<br>
If we make this official (and I agree that by far this is a highly<br>
theoretical point), it means people will start to use and report bugs, </blockquote><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">
and not all bugs can be reduced to a FileCheck. If, OTOH, Google is to<br>
be the only user of this back-end *ever*, then I don't see *any*<br>
reason to move this in-tree other than "saving Google some time",<br>
which is not very sporting.<br></blockquote><div><br>I think Chris Lattner enumerated some valuable points regarding the benefit of having a backend in-tree even if it's never intended for use outside a select group.<br><br>"<span style="font-family:monospace">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 :-)</span></div><br style="font-family:monospace"><span style="font-family:monospace">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.</span><br style="font-family:monospace"><br style="font-family:monospace"><span style="font-family:monospace">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 </span><a href="http://llvm.org/" rel="noreferrer" target="_blank" style="font-family:monospace">llvm.org</a><span style="font-family:monospace">instead of into your local branch.</span><br style="font-family:monospace"><br style="font-family:monospace"><span style="font-family:monospace">4) There could be an educational benefit of having the backend, particularly if it has unique challenges to overcome."</span></div><div class="gmail_quote"> <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">There is a big difference, in my view, between a "technology preview"<br>
and a "cost-cutting decision". </blockquote><div><br></div><div>Cutting costs isn't inherently bad - we all strive for efficiency. The question is if it's the wrong tradeoff (if the wrong groups end up paying for it, or the overall cost is higher, etc).</div><div> </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">Most companies contributing to LLVM<br>
wouldn't care, and they could even contribute their own secret<br>
back-ends to LLVM as a result of it, but my personal and very strong<br>
opinion is that this would ultimately be very bad for the community at<br>
large. LLVM would become a graveyard </blockquote><div><br></div><div>Graveyard sounds like abandoned backends - I think we're all agreed that if a backend (public or private) ever became abandoned, it would be swiftly removed.</div><div> </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">of odd back-ends that don't<br>
relate to each other, </blockquote><div><br></div><div>I'm not sure I follow this - what do you mean by "don't relate to each other" - most of our backends don't relate to each other, do they?</div><div> </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">that can't be proven right or wrong, that can't<br>
be tested or probed and we'd be at the mercy of all companies<br>
supporting them to "fix them as soon as they're able".<br></blockquote><div><br></div><div>Why is that a mercy, though? At any point it's as working as the group that cares about it working is willing to make it. The rest of the community need not care (unless it's abandoned - at which point it should be removed) </div><div> </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">A community that relies on the benevolence of companies is *not* a<br>
healthy community. Not to name names, but I'm sure you can think of a<br>
few related to OO languages and databases.<br>
<br>
So, my view of official back-ends is that:<br>
* It's available to the general public and is of interest to more<br>
than the company maintaining it<br>
* It has a clear way to pass/fail and add regression tests to make<br>
sure we don't break again<br>
* It allows the wider community to work on it, ie. not a selfish<br>
cost-cutting decision<br>
* It has *some* representation outside the company who supports it<br>
<br>
Experimental back-ends, as Chris said, have a much lower threshold.<br>
I'm surprised we still keeping the CppBackend for this long.<br>
<br>
cheers,<br>
--renato<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>