Re-reading the thread, it looks like there is a difference of opinion what "an active community behind the target" means: an active community of LLVM-target-maintainers, and/or an active community of end-users. I'd think the immediate practical concern is that there is an active community of LLVM-target-maintainers, so that the maintenance burden does not fall unduly on the rest of the LLVM community. Beyond that is the broader and vaguer question of whether there is anybody *else* who would benefit from the in-tree target, other than the maintainers. You could think of the former as a "cost" (to the LLVM community) question, and the latter as a "benefit" (beyond the community) question. Or even more succinctly: - does is hurt "us" to have this? - does it help "them" to have this? A secondary point to having an end-user community is that if the initial maintainers drop out for any reason, there is likely to be somebody to take their place, preserving the low-hurt characteristic. As a straw man, if some of us ex-DEC folks wanted to resurrect the Alpha target, I'd think that would be pretty cool, but it's hard to point to anybody that could actually make use of an Alpha-target Clang. So while I suspect there are enough of us around that the "hurt" part could be low to nothing, there's really nobody on the "help" side. And after the Alpha fans die off, well, that's that. I didn't pay enough attention to the Lanai debate to know whether Google has much of an end-user community there. It seems likely the hurt side would not be a problem, even if the current maintainers rotate out for whatever reason then Google seems likely to rotate in somebody else to take their place. That capacity would seem to make it less necessary to identify an end-user community of its own. 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? --paulr> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi > Amini via llvm-dev > Sent: Friday, August 26, 2016 10:05 AM > To: Renato Golin > Cc: LLVM Dev; Alex Rosenberg > Subject: Re: [llvm-dev] [RFC] AAP Backend > > > > On Aug 26, 2016, at 9:55 AM, Renato Golin <renato.golin at linaro.org> > wrote: > > > > On 26 August 2016 at 17:45, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> “Major corporation” does not mean size to me, I read it as “having a > major involvement in the project”. > > > > Still, you're rejecting new developers because they haven't > > contributed much before. > > Can you quote exactly where *I* *rejected* anything? > > > > But if their back-end is upstream, than they'll contribute code > > upstream for their changes on their back-end. > > > > However, if we don't allow their back-end to be upstream, they won't > > contribute to the project. > > > > Looks like a self-defeating argument, and one that still doesn't agree > > with the open source philosophy. > > > > Not to mention that it's an argument that is not required by the > > policy in any way. > > The policy you quote says *must be an active community behind the target”. > The question is *only* about this, so it seems right on point to me. > > > >> “the question is about who will use/develop/maintain this backend > upstream in LLVM?" > > > > They have answered that question. Ed and Simon will be the active > > maintainers. I imagine they have other developers around to help. > > I don't see *any* concern here, nor any violation of the policy. Like > > the Lanai back-end, the community is the maintainers. LGTM. > > See above quote from the policy. > > > > > >> "is there already an open-source community around this backend > somewhere?" > > > > This is not a requirement of the policy, nor was a requirement to any > > other back-end, so not a valid argument. > > Asking a question is not an argument. > > > > > > If we were to reject changes for not having an open source community > > elsewhere, we'd be chopping a very large parts of LLVM off. > > I didn’t write that, and *I* didn’t ask any rejection. In short my only > question is “what is the community around this”? (And I didn’t even start > the question but found it interesting). > > — > Mehdi > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/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
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>
Given the large amount of feedback, I felt I should add some more context/answer some of the question raised. Internally, the work on AAP is led by me and assisted by Simon Cook. We also have Andrew Burgess, Graham Markall and Jeremy Bennett who are also working on the project. There are no traditional end-users, but the target audience isn't the same as for most backends. Despite this it is still an open platform and the hardware design runs readily on low-cost FPGA boards used in education. AAP is aimed at individuals or groups developing backends for deeply embedded systems. It may not be possible to upstream these backends because it would reveal too many architecture details, because it is only for internal use, or because it would require too many generic changes. For these architectures, there aren't any reference architectures in the public LLVM code base on which to base their work. Equally, there are no in-tree architectures which can serve as a vehicle for any improvements they would otherwise share. There are a lot of embedded architectures out there, and we think it is desirable to lower the barrier of entry to make it easier for these to go in tree. As for the backend itself, the initial patches don't require any significant changes to generic code, and should not cause a development burden. As LLVM advances and we make changes to the backend, we expect to maintain it appropriately to keep up. Eventually we will make proposals which do touch on generic code, since one of the key reason of AAP is to advance LLVM. These will of course go through the normal review process, and would hopefully be accepted as useful improvements to LLVM on the whole. Thanks, Edward Jones On 26/08/16 19:54, Robinson, Paul via llvm-dev wrote:> Re-reading the thread, it looks like there is a difference of opinion > what "an active community behind the target" means: an active community > of LLVM-target-maintainers, and/or an active community of end-users. > > I'd think the immediate practical concern is that there is an active > community of LLVM-target-maintainers, so that the maintenance burden > does not fall unduly on the rest of the LLVM community. Beyond that > is the broader and vaguer question of whether there is anybody *else* > who would benefit from the in-tree target, other than the maintainers. > You could think of the former as a "cost" (to the LLVM community) > question, and the latter as a "benefit" (beyond the community) question. > Or even more succinctly: > - does is hurt "us" to have this? > - does it help "them" to have this? > A secondary point to having an end-user community is that if the > initial maintainers drop out for any reason, there is likely to be > somebody to take their place, preserving the low-hurt characteristic. > > As a straw man, if some of us ex-DEC folks wanted to resurrect the > Alpha target, I'd think that would be pretty cool, but it's hard to > point to anybody that could actually make use of an Alpha-target Clang. > So while I suspect there are enough of us around that the "hurt" part > could be low to nothing, there's really nobody on the "help" side. > And after the Alpha fans die off, well, that's that. > > I didn't pay enough attention to the Lanai debate to know whether > Google has much of an end-user community there. It seems likely the > hurt side would not be a problem, even if the current maintainers > rotate out for whatever reason then Google seems likely to rotate in > somebody else to take their place. That capacity would seem to make > it less necessary to identify an end-user community of its own. > > 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? > > --paulr > > >> -----Original Message----- >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi >> Amini via llvm-dev >> Sent: Friday, August 26, 2016 10:05 AM >> To: Renato Golin >> Cc: LLVM Dev; Alex Rosenberg >> Subject: Re: [llvm-dev] [RFC] AAP Backend >> >> >>> On Aug 26, 2016, at 9:55 AM, Renato Golin <renato.golin at linaro.org> >> wrote: >>> >>> On 26 August 2016 at 17:45, Mehdi Amini <mehdi.amini at apple.com> wrote: >>>> “Major corporation” does not mean size to me, I read it as “having a >> major involvement in the project”. >>> >>> Still, you're rejecting new developers because they haven't >>> contributed much before. >> >> Can you quote exactly where *I* *rejected* anything? >> >> >>> But if their back-end is upstream, than they'll contribute code >>> upstream for their changes on their back-end. >>> >>> However, if we don't allow their back-end to be upstream, they won't >>> contribute to the project. >>> >>> Looks like a self-defeating argument, and one that still doesn't agree >>> with the open source philosophy. >>> >>> Not to mention that it's an argument that is not required by the >>> policy in any way. >> >> The policy you quote says *must be an active community behind the target”. >> The question is *only* about this, so it seems right on point to me. >> >> >>>> “the question is about who will use/develop/maintain this backend >> upstream in LLVM?" >>> >>> They have answered that question. Ed and Simon will be the active >>> maintainers. I imagine they have other developers around to help. >>> I don't see *any* concern here, nor any violation of the policy. Like >>> the Lanai back-end, the community is the maintainers. LGTM. >> >> See above quote from the policy. >> >> >>> >>>> "is there already an open-source community around this backend >> somewhere?" >>> >>> This is not a requirement of the policy, nor was a requirement to any >>> other back-end, so not a valid argument. >> >> Asking a question is not an argument. >> >> >>> >>> If we were to reject changes for not having an open source community >>> elsewhere, we'd be chopping a very large parts of LLVM off. >> >> I didn’t write that, and *I* didn’t ask any rejection. In short my only >> question is “what is the community around this”? (And I didn’t even start >> the question but found it interesting). >> >> — >> Mehdi >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >