[llvm-dev] [RFC] AAP Backend

[Renato Golin via llvm-dev]

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.

cheers,
--renato