[llvm-dev] [RFC] Lanai backend

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 10 07:56:36 PST 2016

On 10 February 2016 at 15:30, Alexei Starovoitov
<alexei.starovoitov at gmail.com> wrote:
> BPF backend has been the first class citizen for a year or so.
> All major linux distros ship llvm with it turned on.
> (unlike some other backends)
> BPF buildbot processes more commits than arm64 :)

The BPF back-end is, indeed, built by default, but the nomenclature of
"first class citizen" is hazy. I don't think we ever got around
defining it properly and the list that used to mean that [1] is
severely outdated.

The page that may have a bit more meaning is [2], when it states the
criteria for quality as:

1. Code must adhere to the LLVM Coding Standards.
2. Code must compile cleanly (no errors, no warnings) on at least one platform.
3. Bug fixes and new features should include a testcase so we know if
the fix/feature ever regresses in the future.
4. Code must pass the llvm/test test suite.
5. The code must not cause regressions on a reasonable subset of
llvm-test, where “reasonable” depends on the contributor’s judgement
and the scope of the change (more invasive changes require more
testing). A reasonable subset might be something like

Item 2 above cannot apply to the BPF of Lanai back-ends. We normally
use a stronger criteria saying that the code "must build on at least
one *major* platform", that normally meaning x86 or ARM32/64, maybe
Mips or PPC? Since most people develop on an x86 anyway, that ends up
being the common line.

Having said that, item 2 above doesn't apply to most LLVM back-ends,
so that's not a good criteria for "first class citizen".

In my view, a "first class citizen" is a target (not just the
back-end) that is supported throughout its life-cycle. Meaning you can
prove that user code (including benchmarks) can correctly run on your
target at expected speeds. If you pass the FileCheck tests but no one
can use the results, than I *cannot* assert that your target is
"supported". I can create an infinite number of tests that do nothing
and say my fake target has a million tests passing and they finish in
under 10 seconds, but that is also pointless.

The BPF back-end has a real use case and indeed a lot of good tests,
but I don't know if your buildbots test the resulting code in a kind
of simulator or if you have added real code to the regression tests,
so that we can spot one some of them stop working. If that's so, then
it fits all (my personal) criteria of a "first class citizen". If GPU
targets' buildbots do test the resulting code in their GPUs, then the
same apply to them.

Right now, the Lanai back-end has no means of execution by the
community, so could never become a "first class citizen". In the event
that Google puts up a public buildbot with a Lanai
simulator/emulator/hardware and passes the appropriate tests, it'll be
a community-expensive target to have (because reproducibility is only
allowed to one company), but could become a "supported" back-end IFF
Google is quick enough to solve all problems. If Google releases an
emulator public, then it'll be a lot easier to make the target
"supported" and promote it to a "first class citizen".


[1] http://llvm.org/docs/GettingStarted.html#requirements
[2] http://llvm.org/docs/DeveloperPolicy.html#quality

More information about the llvm-dev mailing list