[LLVMdev] RFC: Staging area proposal for new backends

[Chris Lattner]

On Jul 20, 2012, at 8:51 AM, Tom Stellard wrote:
> The goals of the staging area will be:
>  1. Facilitate communication between the LLVM project and backend
>     developers
>  2. Ensure that new backends meet LLVM standards
>  3. Give the backend more exposure to users and prospective developers

FWIW, I really like this idea or concept, but we have to be careful for it to be done right. This is also more general than just backends: experimental optimizers and runtime libraries can also benefit from something like this.

> ++ Staging Area:
> 
> Similar to the Linux kernel, the staging area for new backends will
> be in the main LLVM tree, with building of the backend being disabled
> by default.

Makes sense.  Them being in the main tree isn't a problem as long as they aren't built by default, tested in buildbots, etc.

> 1. It will be easier for LLVM developers to become familiar with the
>   new backend and identify areas for improvement.
> 
>  If the new backend is in the main tree, LLVM developers are more
>  likely to encounter it in their day to day development.  Imagine a
>  scenario where a developer makes a change to LLVM core that impacts
>  several backends.  The developer may grep the code looking for
>  backends that make use of the feature that they have added or
>  changed.

This makes sense, but it should not be a *requirement* that API changes don't break experimental backends.  This would be the responsibility of the contributors/owner of that backend and/or steward to make sure it keeps building.  Of course it's great for someone to update all the experimental backends if they want, but it shouldn't be a requirement.

>  If the backend were staged in a separate tree, this kind of
>  simple review would not be possible, and I would be concerned that
>  developers would be too busy to ever get around to checking out
>  the staging tree.

Yep.

> 2. It will allow the backend developers to always develop against TOT.
> 
>  Developing against TOT is the recommended development procedure for
>  anyone working on LLVM, and this is regularly reiterated on the
>  mailing list.  If the new backend is included in the main tree,
>  the backend developers will have no choice but to work against TOT.

+1!!!

> 3. It will make it easier for end users and distributions to test and
>   also make it easier for new contributors.
> 
>  New backends will be more visible to the public if they are in the
>  main tree.  This will mean more users, an expanded testing base, and
>  more potential developers which will lead to a higher quality backend.

I'd also add:

4. Infrastructure enhancements that are only required for an experimental backend can be implemented in the main tree, even if that infrastructure isn't needed by other targets.  Of course, these changes need to meet the standard quality bar for general code in the compiler.

In the past, we've had some general infrastructure features get denied because they didn't relate to any targets in-tree.

> ++ What is needed from the LLVM developers:
> 
>  In order to make this staging program successful, the LLVM project
>  will need to appoint a "code owner" for the staging process, who
>  backend developers can contact when they are interested in getting
>  the backend included in the main tree.  An LLVM developer will also
>  be needed to act as a steward for the new backend and help guide
>  the backend developers through the process.

I think we also need to define the minimum quality bar for a backend to be included.

Also, if we do this, can we demote CellSPU? :)

-Chris