[llvm-dev] [RFC] Make Lanai backend non-experimental

[Chandler Carruth via llvm-dev]

On Tue, Jul 19, 2016 at 9:42 AM Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 19 July 2016 at 17:04, Martin J. O'Riordan via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Presumably if my out-of-tree backend was to be pushed to LLVM, it too
> would be considered experimental.
>
> Yes. Though, not all out-of-tree back-ends end up upstream for
> different reasons.
>
> A few basic rules to get accepted are if:
>  * the target exists and can be easily purchased / emulated for
> investigating problems,
>  * there are official documents / specs published by the project /
> company that maintains the targets,
>

Most of your list makes a lot of sense to me Renato, but these two items
don't really.

I think a large number of targets in tree would be *extremely* hard to
purchase and directly investigate problems. As examples:

- Hexagon
- SystemZ
- XCore

I'm sure it is theoretically possible for me to acquire such a system and
test on it, but the amount of time and energy it would take make it a
practical impossibility.

Even for fairly pedestrian backends such as AArch64 and PowerPC, we
routinely have people ask active developers on those backends to do the
triaging of issues. I've never seen this be a problem in practice, and I'm
not convinced that it is something we should actually require to have an
upstream backend.


I also worry that we have backends for targets that don't have any (real)
published ISA spec. I'm not sure there is a formal "spec" per-se for BPF.
And perhaps there is a spec for AMDGPU or Hexagon, but even when I've asked
developers on those backends about problems, they've not pointed be at the
published ISA documentation.


And I don't think any of these backends are bad or should be removed. I
rather like several of them. =] I just think that sufficient community
involvement makes the availability of hardware/emulator "nice to have" but
not essential, and it makes the ISA documentation substantially less
important.


The rest of your list below though, I think is a great list.


>  * there is a reasonable community maintaining the rest of the system
> (firmware, OS, other tools, etc),
>  * enough people commit themselves to maintain the LLVM back-end to
> avoid bit-rot,
>  * the back-end is free of contentious features that would mean
> breaking every other target.
>
> For example:
>  * a PIC back-end ticks many of the boxes, but it doesn't have a
> community around it and would very quickly bit-rot,
>  * the CHERI back-end has an active community and interested
> developers, but it would disrupt the IR too much,
>  * the BPF back-end has been added mostly as-is and is actively
> maintained, so gained the status of non-experimental.
>
> The main difference between experimental and official is that they get
> built by default. So, if you don't specify them at CMake time, they
> will be built and their tests will execute, which is a big win for the
> back-end maintainers (as they get free testing), but it's also a big
> burden on other developers if their tests are not independent enough
> and keep breaking due to unrelated changes.
>
> Under those conditions, it's as easy to remove a back-end that is too
> much trouble and no one cares about, as it to add a new experimental
> back-end or promote it to official. It all depends on the community
> around it and how much they value the LLVM back-end.
>
>
> >  But what is involved in making a particular target, feature or back-end
> experimental other than simply agreement?  Are there particular build
> processes or '-Dmacroname's to add, or how does somebody like me edit my
> out-of-tree sources so that it would obey the "is experimental" rules?
>
> I'm assuming you already have an implementation, for example, in
> GitHub. The easiest way to get things started is to point people at
> the repository and make sure it works on trunk.
>
> The second step, then, would be to merge that into the tree and
> propose to include it as an experimental target. It will take a few
> months until the process is complete and then you'll be able to check
> it out and work straight from LLVM's repository.
>
> You'll have to change the CMake to force it to be built
> (-DLLVM_TARGETS_TO_BUILD) until such time that you have shown that you
> care about the target and that it hasn't failed (best if you have a
> buildbot showing the history always green).
>
> Once all that is done, you can do as Jacques did and request it to be
> built by default (aka. non-experimental, aka. official back-end).
>
> After that change, though, you're permanently enlisted to maintain it
> even more intensely. Not just your buildbot will break, but other
> people's too, and they're probably a lot faster than yours, so you
> need to keep an eye on them, especially if they break due to unrelated
> commits.
>
> That is the contract that you have to sign to have your target
> supported, and if you break that contract (let it bit-rot, disable
> tests that should be passing, remove parts of the code, or just
> neglects bug reports), your back-end *will* be removed.
>
> Hope that helps,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160725/be299207/attachment.html>