Eric Christopher
2012-Jul-16 20:21 UTC
[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
Tom Stellard
2012-Jul-16 20:26 UTC
[LLVMdev] [llvm-commits] RFC: LLVM incubation, or requirements for committing new backends
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] mesa3d.org
Sean Silva
2012-Jul-17 00:13 UTC
[LLVMdev] [llvm-commits] RFC: LLVM incubation, or requirements for committing new backends
> [...] 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] mesa3d.org > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Maybe Matching Threads
- [LLVMdev] [llvm-commits] RFC: LLVM incubation, or requirements for committing new backends
- [LLVMdev] [llvm-commits] RFC: LLVM incubation, or requirements for committing new backends
- [LLVMdev] [llvm-commits] RFC: LLVM incubation, or requirements for committing new backends
- [LLVMdev] LLVM as an OpenGL backend
- [LLVMdev] RFC: R600, a new backend for AMD GPUs