<div dir="ltr">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.<div><br></div><div>This would be a first for an LLVM backend AFAIK -- all the other backends have an expected <i>direct </i>user-base, while AAP seems basically artificial. </div><div><br><div>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.</div><div><div><br></div></div><div><div>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.</div></div><div><br></div><div>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.<br></div></div><div><br></div><div>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.</div><div><br><div class="gmail_quote">On Fri, Aug 26, 2016 at 5:34 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 26 August 2016 at 19:54, Robinson, Paul <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<br>
> Regarding AAP, we've got a few target-maintainers, who say they do<br>
> have target-users who could benefit.  Alex asked if the maintainers<br>
> could better quantify their user base, which seems like a reasonable<br>
> question.  Who is on the "help" side?  Would they be able to take<br>
> over from the initial target-maintainers if necessary?<br>
<br>
</span>Hi Paul,<br>
<br>
I agree it's a pertinent question, but it's one that weren't holders<br>
for the recent back-ends, so I think it would be prejudicial to<br>
restrict the AAP target on different terms than the past recent ones.<br>
<br>
Unless I'm interpreting everyone's words completely wrong, like I did<br>
with Mehdi...<br>
<br>
Basically, neither Lanai nor BPF needed a large and/or opensource user<br>
community behind it. Both BPF and RISC-V have basically a sole<br>
maintainer. I don't think any of that is a bad thing, quite the<br>
opposite, both Lanai and BPF back-ends have proven very stable and<br>
interesting, and I have high hopes for RISC-V.<br>
<br>
I'm probably interpreting this wrong, but here's my specific points on<br>
Alex's phrase:<br>
<span class="gmail-"><br>
> "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."<br>
<br>
</span>This is the part that sounds demanding.<br>
<br>
I don't think there's a direct and meaningful correlation between<br>
number of users and maintenance burden. It makes no sense to expect<br>
users to "take over" a compile back-end, and we already have the<br>
"removal on bit-rot" policy that deals with the case in point.<br>
<br>
There is, however, a direct correlation between the interest of<br>
maintainers and the quality of the code, and the BPF back-end has<br>
proven that the number of maintainers can successfully be *one*. AAP<br>
has at least two.<br>
<br>
This is not to say that AAP will be as strong as ARM, X86, PPC or<br>
MIPS, but it see no reason for it not to be as strong as Lanai, BPF,<br>
RISC-V. I'd rather trust their enthusiasm, and foster it, so we can<br>
have a stronger community.<br>
<span class="gmail-"><br>
<br>
> "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.<br>
<br>
</span>Lanai wasn't an exception, it was part of the rule.<br>
<br>
Google has now put up technical documentation and is open sourcing the<br>
emulator. They have guaranteed they will be the maintainers and<br>
responsible for any breakages. They have kept the back-end stable and<br>
green. Nothing that Ed hasn't done or promised.<br></blockquote></div></div></div>