<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 7:56 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10 February 2016 at 15:30, Alexei Starovoitov<br>
<span class=""><<a href="mailto:alexei.starovoitov@gmail.com">alexei.starovoitov@gmail.com</a>> wrote:<br>
> BPF backend has been the first class citizen for a year or so.<br>
> All major linux distros ship llvm with it turned on.<br>
> (unlike some other backends)<br>
> BPF buildbot processes more commits than arm64 :)<br>
<br>
</span>The BPF back-end is, indeed, built by default, but the nomenclature of<br>
"first class citizen" is hazy. I don't think we ever got around<br>
defining it properly and the list that used to mean that [1] is<br>
severely outdated.<br>
<br>
The page that may have a bit more meaning is [2], when it states the<br>
criteria for quality as:<br>
<br>
1. Code must adhere to the LLVM Coding Standards.<br>
2. Code must compile cleanly (no errors, no warnings) on at least one platform.<br>
3. Bug fixes and new features should include a testcase so we know if<br>
the fix/feature ever regresses in the future.<br>
4. Code must pass the llvm/test test suite.<br>
5. The code must not cause regressions on a reasonable subset of<br>
llvm-test, where “reasonable” depends on the contributor’s judgement<br>
and the scope of the change (more invasive changes require more<br>
testing). A reasonable subset might be something like<br>
“llvm-test/MultiSource/Benchmarks”.<br>
<br>
Item 2 above cannot apply to the BPF of Lanai back-ends. We normally<br>
use a stronger criteria saying that the code "must build on at least<br>
one *major* platform", that normally meaning x86 or ARM32/64, maybe<br>
Mips or PPC? Since most people develop on an x86 anyway, that ends up<br>
being the common line.<br>
<br>
Having said that, item 2 above doesn't apply to most LLVM back-ends,<br>
so that's not a good criteria for "first class citizen".<br></blockquote><div><br></div><div>I think that's perhaps not the right interpretation of (2) - it looks to me like rule 2 is talking about the code in question (the backend), not the code it can generate. (eg: when the Clang AST matchers were contributed, rule 2 applies equally there - that the code for the matchers must compile cleanly without warnings or errors on at least one platform (I take it the "on at least one platform" is for the sake of platform specific code/features - like code to support running the compiler on Windows (as distinct from the Windows support for the output of Clang)))<br><br>I don't think this rule has anything to do with backends and what they can/cannot generate.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In my view, a "first class citizen" is a target (not just the<br>
back-end) that is supported throughout its life-cycle. Meaning you can<br>
prove that user code (including benchmarks) can correctly run on your<br>
target at expected speeds. If you pass the FileCheck tests but no one<br>
can use the results, than I *cannot* assert that your target is<br>
"supported". I can create an infinite number of tests that do nothing<br>
and say my fake target has a million tests passing and they finish in<br>
under 10 seconds, but that is also pointless.<br></blockquote><div><br></div><div>Sure - and we wouldn't accept those, nor would anyone propose them.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The BPF back-end has a real use case and indeed a lot of good tests,<br>
but I don't know if your buildbots test the resulting code in a kind<br>
of simulator or if you have added real code to the regression tests,<br>
so that we can spot one some of them stop working. If that's so, then<br>
it fits all (my personal) criteria of a "first class citizen". If GPU<br>
targets' buildbots do test the resulting code in their GPUs, then the<br>
same apply to them.<br>
<br>
Right now, the Lanai back-end has no means of execution by the<br>
community, so could never become a "first class citizen". In the event<br>
that Google puts up a public buildbot with a Lanai<br>
simulator/emulator/hardware and passes the appropriate tests, it'll be<br>
a community-expensive target to have (because reproducibility is only<br>
allowed to one company), but could become a "supported" back-end IFF<br>
Google is quick enough to solve all problems.</blockquote><div><br></div><div>This seems odd to me - and much like the discussions we've previously had about buildbots. If only group X cares about hardware Y then I think it's an entirely acceptable community behavior for group X to run tests internally and be responsible for triaging failures on Y and communicating that back to the community in whatever timeline is important to them - since the hardware isn't of interest to anyone else. Having a bot that sends mail is where the urgency is created that requires the bot to be of high quality, its results to be independently actionable, etc - but I don't see it as a necessity & I think other targets we already have could benefit from that approach even though their hardware is public/accessible (for a price, that no one generally pays). Most of us only have one architecture available to us (maybe two - X86/desktop hardware + test hardware of the target we're working on), so we just care that when something says "something is broken" we can act on that. I don't personally mind if that is automated or not - but the longer the latency the more onus is on the invested group to do the legwork. They can expect to be broken and for the codebase to have moved on by the time they root cause (& have to do more work to figure out where/how to fix it - becomes more of a discussion with the community members with more onus on the target owners, etc) - this happens today with high latency bots, etc. Doesn't seem like anything new.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If Google releases an<br>
emulator public, then it'll be a lot easier to make the target<br>
"supported" and promote it to a "first class citizen".<br>
<br>
cheers,<br>
--renato<br>
<br>
[1] <a href="http://llvm.org/docs/GettingStarted.html#requirements" rel="noreferrer" target="_blank">http://llvm.org/docs/GettingStarted.html#requirements</a><br>
[2] <a href="http://llvm.org/docs/DeveloperPolicy.html#quality" rel="noreferrer" target="_blank">http://llvm.org/docs/DeveloperPolicy.html#quality</a><br>
<div class="HOEnZb"><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>