[LLVMdev] RFC: Staging area proposal for new backends
Justin Holewinski
justin.holewinski at gmail.com
Fri Jul 27 10:30:49 PDT 2012
On 07/27/2012 01:01 PM, Tom Stellard wrote:
> Hi,
>
> I would like to try to keep the staging area discussion going. There
> seems to be a general consensus that a staging area for backends and also
> new features would be acceptable for the LLVM project. What actions
> are required to make the staging area a reality? Is more discussion
> needed? Is anyone willing to volunteer to be the "Code Owner" for the
> staging area, to help move the process forward?
>
> Thanks,
> Tom
The main issue I see is defining exactly how to incorporate the "staged"
back-ends into the build system. I see a couple of possibilities.
1. Fully-integrate the "staged" back-ends into the CMake/Autotools
build systems, but exclude them from the "all" pseudo-target.
2. Maintain a separate list of "staged" back-ends, and create an
additional option that must be set in order to build them (with an
appropriate warning).
We also need to come up with a plan regarding cutting releases. When 3.2
is branched, will all "staged" back-ends be removed? Or will they be
left in the distribution so interested parties can build them?
Beyond that, I don't believe we have established the criteria for
back-end promotion. Then again, it may make more sense to use R600 as a
guinea pig and address issues as they come up.
>
> On Fri, Jul 20, 2012 at 11:51:03AM -0400, Tom Stellard wrote:
>> Hi,
>>
>> I would like to follow up on the recent discussion on the mailing list
>> about requirements for new backends[1] by submitting the following
>> proposal for a staging area for new LLVM backends. This proposal
>> incorporates ideas from Owen, Chandler, and others who chimed in on
>> the original thread, and I hope the LLVM developers will be able to
>> come to a consensus on this proposal or a modified version, so the
>> project is able to accept new backends.
>>
>> 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
>>
>> ++ 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. There will also be a TODO file in the backend's root
>> directory, that contains a list of improvements that are required to
>> promote the backend out of the staging area. The backend will be
>> assigned a steward who's role will be to guide the backend through
>> the staging process and help solicit feedback from other developers.
>>
>> There are several advantages to having the staging area be in the main
>> tree as opposed to a separate branch:
>>
>> 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. If the new backend is in tree and uses that feature,
>> the developer will see the code and might take a few moments to
>> read through. While doing this the developer may notice an area for
>> improvement for the backend and can update the backends's TODO file.
>> The end result of this is that the LLVM developer has been able to
>> provide some feedback with a minimal time commitment on their part.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>>
>> ++ Promotion/Demotion from staging area:
>>
>> After a period of time, or when the tasks in the TODO file have been
>> completed, the backend developers or the steward can initiate the
>> review process. The review process will be conducted by either the
>> steward, a committee, or some select developers, who will decide
>> (maybe by vote in the case of a committee) whether the backend
>> should be:
>>
>> - Promoted = Build of backend will be enabled by default.
>> - Extended = Backend remains in the staging area.
>> - Demoted = Removed from the main tree
>> (I can't really think of any disadvantages to having a backend be
>> in the main tree as long as its not being built by default, so maybe
>> demotion would be reserved for cases of long term absence
>> of maintainership)
>>
>> The Promoted/Extended/Demoted decision will be made using the
>> following criteria (These won't necessarily all be absolutely
>> required, they merely serve as a way for a backend's progress to
>> be measured) :
>>
>> - Progress towards completion of TODO tasks
>> - Active maintainership
>> - Use of incremental development techniques
>> - Adherence to LLVM coding style
>> - Usage of modern LLVM features
>> - Quality and quantity of regression tests
>> - Availability of buildbots
>> - Size of user base
>> - Other criteria deemed important by LLVM developers
>>
>> - Contributions to core LLVM
>> In the previous mailing list discussions there were differing
>> opinions of how important contributing to the core LLVM code is
>> for having a backend accepted. It seems like a good middle ground
>> would be that backends should be free of code that works around
>> bugs or deficiency in core LLVM and instead fix the problem in
>> shared code, and also should make an effort to push optimization
>> passes that may be useful to other targets into the shared parts
>> of the code.
>>
>>
>> ++ 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.
>>
>> Looking forward to comments on this proposal.
>>
>> Thanks,
>> Tom Stellard
>>
>> [1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120716/146560.html
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
--
Thanks,
Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120727/e24f5cfc/attachment.html>
More information about the llvm-dev
mailing list