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

On Jul 16, 2012, at 1:17 PM, Tom Stellard <thomas.stellard at amd.com>
wrote:
> 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".
Actually a branch is a better idea for a couple of reasons:

1) It'll help show that you're dedicated to the idea of maintaining the
target, and
2) If the overhead of merging is too high for the target there are probably
patches
that need to be either a) upstreamed or b) the target needs to be rewritten
since it
shouldn't affect the main code base.

The part about other users is a good idea, but how often are users (not
developers)
checking out a copy of random ToT llvm in order to use it?

-eric

On Mon, Jul 16, 2012 at 01:21:18PM -0700, Eric Christopher
wrote:
> 
> On Jul 16, 2012, at 1:17 PM, Tom Stellard <thomas.stellard at
amd.com> wrote:
> 
> > 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".
> 
> Actually a branch is a better idea for a couple of reasons:
> 
> 1) It'll help show that you're dedicated to the idea of maintaining
the target, and
> 2) If the overhead of merging is too high for the target there are probably
patches
> that need to be either a) upstreamed or b) the target needs to be rewritten
since it
> shouldn't affect the main code base.
> 
> The part about other users is a good idea, but how often are users (not
developers)
> checking out a copy of random ToT llvm in order to use it?
>
This is very common for users of the Mesa Project[1], which the R600/SI
backend is currently a part of.  Also some distributions package the
current TOT of various projects to offer users an easy way to try out the latest
code.

-Tom

[1] http://www.mesa3d.org

> [...] Also some distributions package the
> current TOT of various projects to offer users an easy way to try out the
latest code.
This would still require going to every such distribution and telling
them to flip the special build flag that enables building the
"backends-in-training".

--Sean Silva

On Mon, Jul 16, 2012 at 1:26 PM, Tom Stellard <thomas.stellard at amd.com>
wrote:
> On Mon, Jul 16, 2012 at 01:21:18PM -0700, Eric Christopher wrote:
>>
>> On Jul 16, 2012, at 1:17 PM, Tom Stellard <thomas.stellard at
amd.com> wrote:
>>
>> > 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".
>>
>> Actually a branch is a better idea for a couple of reasons:
>>
>> 1) It'll help show that you're dedicated to the idea of
maintaining the target, and
>> 2) If the overhead of merging is too high for the target there are
probably patches
>> that need to be either a) upstreamed or b) the target needs to be
rewritten since it
>> shouldn't affect the main code base.
>>
>> The part about other users is a good idea, but how often are users (not
developers)
>> checking out a copy of random ToT llvm in order to use it?
>>
>
> This is very common for users of the Mesa Project[1], which the R600/SI
> backend is currently a part of.  Also some distributions package the
> current TOT of various projects to offer users an easy way to try out the
latest code.
>
> -Tom
>
> [1] http://www.mesa3d.org
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits