<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jul 25, 2016 at 4:49 PM Matthias Braun via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The question I want answered as a community member, is what happens when I push a patch to say the register allocator or the scheduler and the lanai buildbot reports a breakage. While I should obviously revert my patch how would I go forward when I cannot figure out the reason? This is especially bad if I can't get access to additional information to understand the generated instructions; Lanai is still missing from docs/CompilerWriterInfo.rst for example.<br></blockquote><div><br></div><div>There are two kinds of failures:</div><div><br></div><div>1) A lanai build bot fails an *execution* test using some (perhaps private) emulator.</div><div><br></div><div>2) A lanai regression test fails (regardless of what bot it fails on).</div><div><br></div><div>For #1, I think in practice for a number of our backends, this is already going to fall largely on the heads of backend maintainers to get a useful test case to you or otherwise help you re-land your patch. If they can't do so promptly, I would expect it to be reasonable to XFAIL the test until they have time to work on it and make it entirely the backend maintainers' problem.</div><div><br></div><div>For #2, the amount of ISA documentation made available for that architecture directly dictates how much time it is reasonable for you to spend fixing the test. If there are no docs, you shouldn't be doing more than fixing *obvious* test failures. Anything else should just get XFAILed and you should move on and leave it to the maintainers. If there is reasonable documentation to make small test cases understandable to roughly anyone, then great. You can spend somewhat more time trying to update things.</div><div><br></div><div>But for *both* of these, Chris's principle should still apply: does the engagement in common LLVM infrastructure work of the backend maintainers outweigh the non-zero maintenance cost imposed on the upstream project.</div><div><br></div><div>My hope is that for relatively simple backends, the maintenance cost can be close enough to zero that given sufficiently active maintainers it is usually a win for the project to have them in tree. To that end, I like backend maintainers providing enough ISA documentation for developers to quickly make simple updates to tests, and I simultaneously like to *not* have developers make complex updates to tests for a particular backend just because they changed the infrastructure, and instead I'd like to see more things along the lines of you and others saying: "Temporarily XFAIL various target tests, maintainers are aware and will work on updating these tests once the infrastructure change lands." to expedite improvements to the core.</div><div><br></div><div>My view is that keeps the cost of a backend low in order to allow the community to benefit from the diverse developers of those backends.</div><div><br></div><div>None of this requires a simulator though, because by the time you or someone else working on basic infrastructure need access to a simulator or hardware for a platform you're not actively maintaining, I think the cost has usually already gotten too high. We should already be pushing that burden onto those who care about that backend.</div><div><br></div><div>Hope that makes some sense...</div><div>-Chandler</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- Matthias<br>
<br>
> On Jul 25, 2016, at 4:18 PM, Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On 26 July 2016 at 00:08, Chris Lattner via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> It is unquestionably easier for a contributor to land their backend in-tree<br>
>> than to maintain it out-of-tree.  This is because landing it in tree shifts<br>
>> the maintenance burden from the *contributor* to the *community*.  If there<br>
>> is low value to the community, then this is a "bad deal” for the project as<br>
>> a whole, since there is only so much attention to go around.<br>
><br>
> This expresses my idea very clearly.<br>
><br>
> The initial Lanai thread had hints that this could be at play, though<br>
> they seem to be releasing emulators and documents, which to mee it<br>
> seems like that was just FUD.<br>
><br>
> However, the fact that people did consider it means they care about<br>
> not being tossed a piece of code to baby sit, and this has *nothing*<br>
> to do with the license.<br>
><br>
> I'll start the discussion in a new thread, since it's not appropriate<br>
> to steal the Lanai discussion to that topic. Please, let's continue<br>
> there (Target Acceptance Policy).<br>
><br>
> cheers,<br>
> --renato<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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>
</blockquote></div></div>