[llvm-dev] [RFC] AAP Backend

[James Y Knight via llvm-dev]

To me, the difference with AAP is that it's not actually intended to be
useful for any end-users in itself, but, rather, be indirectly useful in
that it can help LLVM upstream be better suited for out-of-tree embedded
CPUs that have somewhat similar characteristics.

This would be a first for an LLVM backend AFAIK -- all the other backends
have an expected *direct *user-base, while AAP seems basically artificial.

IMO, LLVM should not accept artificial instruction sets -- in general. I'd
argue that if someone invents a new instruction set, and is willing to
create, contribute, and maintain an LLVM backend for it, it would be a net
detriment to have accept that backend -- despite that it has a dedicated
maintainer -- if it is not going to be useful as anything other than a toy.
This is simply because the presence of the extra code in the codebase
*does* have an impact on all LLVM developers, even if it's relatively minor
for "just another backend", and it's not worth it to include someone's toy
project.

This didn't really need to be discussed in other recent new-backend
discussions -- anyone can easily identify current or highly-likely-future
user-bases for BPF, RISC-V, and WebAsm, so there wasn't really anything to
debate there. For Lanai, we (speaking with LLVM community hat on) needed to
take Google's word for it that there are in fact real implementations and
users of the target, but people were willing to do so due to Google's long
presence in the community. None of that is true for AAP.

However, it seems to me that AAP probably deserves to be an exception to
that general rule (at least unless/until LLVM gains "real" backends
upstream with similar characteristics) due to its goals and design of being
a stand-in for an entire category of real targets with real users which are
under-represented by existing LLVM backends.

Which is all to say, I think it would be a good decision to accept AAP, but
only if it's done by explicitly and knowingly exempting it from an
acceptance criteria that should be imposed on all other backends.

On Fri, Aug 26, 2016 at 5:34 PM, Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 26 August 2016 at 19:54, Robinson, Paul <paul.robinson at sony.com> wrote:
> > Regarding AAP, we've got a few target-maintainers, who say they do
> > have target-users who could benefit.  Alex asked if the maintainers
> > could better quantify their user base, which seems like a reasonable
> > question.  Who is on the "help" side?  Would they be able to take
> > over from the initial target-maintainers if necessary?
>
> Hi Paul,
>
> I agree it's a pertinent question, but it's one that weren't holders
> for the recent back-ends, so I think it would be prejudicial to
> restrict the AAP target on different terms than the past recent ones.
>
> Unless I'm interpreting everyone's words completely wrong, like I did
> with Mehdi...
>
> Basically, neither Lanai nor BPF needed a large and/or opensource user
> community behind it. Both BPF and RISC-V have basically a sole
> maintainer. I don't think any of that is a bad thing, quite the
> opposite, both Lanai and BPF back-ends have proven very stable and
> interesting, and I have high hopes for RISC-V.
>
> I'm probably interpreting this wrong, but here's my specific points on
> Alex's phrase:
>
> > "I don't think we've ever really built up clear guidance on this, but I
> think there needs to be a clear determination that a given target has
> enough active users to make the maintenance burden worth putting into the
> mainline."
>
> This is the part that sounds demanding.
>
> I don't think there's a direct and meaningful correlation between
> number of users and maintenance burden. It makes no sense to expect
> users to "take over" a compile back-end, and we already have the
> "removal on bit-rot" policy that deals with the case in point.
>
> There is, however, a direct correlation between the interest of
> maintainers and the quality of the code, and the BPF back-end has
> proven that the number of maintainers can successfully be *one*. AAP
> has at least two.
>
> This is not to say that AAP will be as strong as ARM, X86, PPC or
> MIPS, but it see no reason for it not to be as strong as Lanai, BPF,
> RISC-V. I'd rather trust their enthusiasm, and foster it, so we can
> have a stronger community.
>
>
> > "In the past, the only exception I can think of is the Lanai backend,
> but in that case we have a strong commitment of multiple employees at a
> major corporation committed to that target's maintenance.
>
> Lanai wasn't an exception, it was part of the rule.
>
> Google has now put up technical documentation and is open sourcing the
> emulator. They have guaranteed they will be the maintainers and
> responsible for any breakages. They have kept the back-end stable and
> green. Nothing that Ed hasn't done or promised.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160826/538a4f8f/attachment.html>