[LLVMdev] RFC: Staging area proposal for new backends
Tom Stellard
tom at stellard.net
Mon Sep 10 07:20:21 PDT 2012
On Sat, Sep 08, 2012 at 09:28:54PM +0200, Dmitry N. Mikushin wrote:
> Dear Tom,
>
> Looks like setting LCOMMDirectiveType in AMDGPUMCAsmInfo.cpp is not
> needed anymore? I commented it out, and then LLVM got compiled fine.
>
Hi,
I posted an updated patch[1] on Friday that included this change, and I just posted
a few more patches[2] with additional fixes.
The code can also be found in my git tree:
http://cgit.freedesktop.org/~tstellar/llvm/ r600-review-v9
The full tree can be downloaded at:
http://cgit.freedesktop.org/~tstellar/llvm/snapshot/llvm-r600-review-v9.zip
-Tom
[1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120903/150064.html
[2] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150193.html
> - D.
>
> 2012/9/6 Tom Stellard <tstellar at gmail.com>:
> > Hi,
> >
> > Now that --enable-experimental-targets build flags have been added to
> > the build systems. What needs to be done in order to get the R600
> > backend added as an experimental target? I've posted an updated
> > version of the backend to llvm-commits[1], that addresses many of the
> > criticisms of the backend, but I haven't received any feedback, and I
> > feel like the submission process has stalled. It seems like the
> > problem might be that there is not really an established process for
> > adding an experimental target to the tree. So, I'd like to try to
> > re-open this discussion, what steps need to be taken to add an
> > experimental target to the tree?
> >
> > -Tom
> >
> > [1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120827/149491.html
> >
> > On Fri, Jul 20, 2012 at 11:51 AM, Tom Stellard <thomas.stellard at amd.com> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
More information about the llvm-dev
mailing list