[LLVMdev] [llvm-commits] RFC: LLVM incubation, or requirements for committing new backends

[Villmow, Micah]

Owen/Chandler/etc..,
While I have no issue with having a more complete and documented method of submitting backends, the problem is the barrier to entry for some backends is being significantly raised, where they did not exist in the past. In the past AMD has reported issues that we have found from internal development to LLVM, along with patches in some cases. Some have been fixed, but others are unique to our backends and still are not in mainline. Many times the response to attempts to get them fixed has been to get the backend in the mainline development tree first. Now that we are finally able to push our backends out publicly, we are getting pushback that we need to contribute in other places first. While I completely agree with 4 of the five points below, the requirement that we contribute to core for things that are outside the scope of the backend seems overly onerous. Tom's AMDGPU backend is not the only backend AMD would like to push into mainline, as our production AMDIL backend is in the pipeline to be added and AMD has announced that the HSA foundations compiler will also be open sourced(which is a third backend from AMD, plus more, see http://www.phoronix.com/scan.php?page=news_item&px=MTEyMzQ). I would just hate to see these get delayed because of barriers to entry that seem artificial or out of scope of the proposed/required changes.

So I guess the issue is, what else is required to the backends to make them acceptable for LLVM.

Micah

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Tom Stellard
> Sent: Monday, July 16, 2012 1:22 PM
> To: Owen Anderson
> Cc: llvm-commits at cs.uiuc.edu LLVM; LLVM at dcs-maillist.cs.uiuc.edu;
> Developers Mailing List
> Subject: Re: [LLVMdev] [llvm-commits] RFC: LLVM incubation, or
> requirements for committing new backends
> 
> On Mon, Jul 16, 2012 at 11:44:25AM -0700, Owen Anderson wrote:
> > Tom,
> >
> > I think it might be productive to fork this thread to discuss making
> the requirements for upstreaming a new LLVM target more explicit and
> open.  I'd also like to gauge interest in an idea I've discussed
> privately with a few community members, namely the concept of having a
> semi-official "incubation" system whereby proposed backends could get a
> trial run before becoming part of LLVM mainline.
> >
> > The proposed system would be something like this: a proposed
> contribution would receive a branch on llvm.org, and have six months (or
> some other predetermined length of time) to demonstrate that it and its
> developers are ready for mainline integration.  At the end of their
> term, incubated projects would be evaluated on the following criteria,
> and either integrated to mainline, judged to be more appropriate as an
> external project, or given an extension and "needs improvement" feedback
> on specific criteria.
> >
> > * Active maintainership - Backends bit rot quickly, and unmaintained
> backends are large maintenance burden on everyone else.  We need a core
> of developers who are going to actively maintain any candidate backend
> on mainline.  That last point is critical: a code drop every six months
> is not an acceptable level of maintenance for a mainline target.
> >
> > * Contributions to core - Mainlining a new backend adds the
> expectation that mainline LLVM developers will invest the time and
> energy to keep your backend building and working (see test plan, below).
> However, that expectation of extra work doesn't come for nothing: we
> expect you to contribute back fixes and improvements that you find, and
> to work with other community members to coordinate projects as
> appropriate.  When looking at a new backend, I should expect to see few-
> to-no diffs outside of lib/Target/YourBackend, and a few other places
> (Triple.cpp, for example).  All other changes should already be
> upstreamed.
> >
> > * Test plan - If you're going to expect us to maintain and fix your
> code, then you need to have a good answer to how to test it.  This
> includes, but is not limited to, a good set of regression tests that are
> comprehensible to normal developers (so we can fix them when they fail
> due to mainline change), and continuous testing in the form of buildbots
> or other infrastructure (so we can know when a patch breaks your
> backend).
> >
> > * Up to date with mainline - All mainline backends must work with top-
> of-tree LLVM, all of the time.  A candidate for inclusion must be
> developed at, or close to, mainline.  In practice, that probably means
> updating at least once a week, possibly more.
> >
> > * LLVM coding standards - While small deviations can be fixed after
> mainlining, gross violations of the LLVM code standards and conventions
> must be fixed prior to integration.
> >
> > ---
> >
> > So, what would the community think of implementing such a system?
> >
> > --Owen
> >
> 
> Hi Owen,
> 
> I am in favor of this.  I think having specific criteria and time lines
> will be beneficial for both maintainers and reviewers.
> 
> However, instead of having a separate branch, what do you think about
> adding the backend to the main tree, but not building it by default.
> This would make it easier for the backend maintainer to keep it up to
> date and also make it easier for users to test it.  At the same time,
> the backend maintainer would still be responsible for updating it for
> changes to the LLVM core API, so other developers wouldn't need to worry
> about breaking the "backend-in-training".
> 
> -Tom
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev