<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Feb 9, 2016 at 10:30 PM Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Feb 9, 2016, at 10:24 PM, Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> You've raised an important point here Pete, and while I disagree pretty strongly with it (regardless of whether Lanai makes sense or not), I'm glad that you've surfaced it where we can clearly look at the issue.<br>
><br>
> The idea of "it really should have users outside of just the people who have access to the HW" I think is deeply problematic for the project as a whole. Where does it stop?<br>
><br>
> While I may have the theoretical ability to get access to an AVR, Hexagon, MSP430, SystemZ, or XCore processor... It is a practical impossibility. There is no way that I, or I suspect 95% of LLVM contributors, will be able to run code for all these platforms. And for some of them, I suspect it is already the case that their only users have access to specialized, quite hard to acquire hardware (both Hexagon[1] and SystemZ come to mind).<br>
<br>
Yes, I think this is a reasonable point.  The cheapest SystemZ system is somewhere around $75K, so widespread availability isn’t really a relevant criteria for accepting that.<br>
<br>
Given that, I personally have no objection to accepting the port as an experimental backend.  For it to be a non-experiemental backend, I think it needs to have a buildbot running execution tests for the target.  This can either be a simulator or google could host a buildbot on the hardware they presumably have and make the results public.<br></blockquote><div><br></div><div>So, while I'm personally happy with this answer, I'm curious: why do you think this important to have?</div><div><br></div><div>I can imagine several reasons myself, in the order they floated to mind:</div><div>1) Makes sure it isn't vaporware and actually works, etc.</div><div>2) Ensures a fairly easy way to tell if the maintainers have gone out to lunch - no build bot stays working without some attention.</div><div>3) Make it more clear whether a change to LLVM breaks that target</div><div><br></div><div>Are there other issues you're thinking about?</div><div><br></div><div>Looking just at these three, they all seem reasonable goals. I can see other ways of accomplishing #1 and #2 (there are lots of ways to establish community trust), but cannot see any other way of accomplishing #3.</div><div><br></div><div>But I also see another option, which someone else mentioned up-thread: simply make only the regression tests be supported. Without a regression test case that exhibits a bug, no reverts or other complaints. It would be entirely up to the maintainer to find and reduce such test cases from any failure of execution tests out-of-tree.</div><div><br></div><div>I prefer this option for perhaps a strange reason: as an LLVM developer I would find it *more* appealing to only ever have to care about <insert-random-target> once the maintainer produced a reduced test case for me. Having a buildbot check the execution and fail is actually not terribly helpful to me in most cases. Sometimes I was already suspicious of a patch and it helpfully confirms my suspicions, but most of the time I'm going to need a test case to do anything useful with the failure and I won't have the tools necessary to produce that test case merely because there is a build bot.</div><div><br></div><div>Anyways, as I said, I think this is somewhat theoretical at this point, but it seems useful to kind of pin down both what our expectations are and *why*.</div><div><br></div><div>-Chandler</div></div></div>