On Fri, Apr 09, 2010 at 05:22:17PM +0200, Duncan Sands wrote:> Hi Jack, > >>>> Is there a timeline for when dragonegg might be >>>> merged into gcc (4.6 perhaps)? I ask because FSF gcc >>>> has allowed code in as technology previews before. >>>> For instance, graphite really wasn't that usable in >>>> gcc 4.4 and produced wrong code in the Polyhedron >>>> 2005 benchmarks until gcc 4.5. So as long as it can bootstrap >>>> gcc 4.6 and works in general, dragonegg should qualify >>>> for inclusion as an experimental plugin. >>> >>> I hadn't really thought about adding dragonegg to the gcc codebase. >>> What do you see as the advantages of doing so? > >> I thought that gcc plug-ins were meant to become part of >> the FSF gcc source code, no? In any case, if dragonegg were >> in the FSF gcc source code, it would have much higher >> visibility and a better chance that some of the existing >> FSF gcc developers would tinker with it on the side. > > another advantage of having plugins in the gcc repository is that when a gcc > developer makes an API change they will (hopefully) fix the plugin as well as > the rest of the code. On the other hand, there's the same advantage to being > in the LLVM repository: LLVM developers will (hopefully) fix dragonegg when > they make an API change, though it has to be said that Chris broke dragonegg > several times recently but didn't notice :) LLVM is changing far more than > gcc as far as dragonegg is concerned, suggesting that the LLVM repository is > a better place to live. > > As for visibility, you are probably right that many more people would become > aware of dragonegg if it was part of gcc. I'm not sure that that's a real > argument though, because a good "advertising campaign" would probably be much > more effective as far as visibility is concerned than including dragonegg in > the gcc repository. As for gcc developers tinkering with it - well, indeed > they might, who can say? Dragonegg does already get a small amount of gcc > visibility already, since I submit gcc patches for dragonegg issues from time > to time, but as far as I know no gcc developers ever tried it. > > Ciao, > > Duncan.Duncan, I'll broach the topic on gcc at gcc.gnu.org and see what the responses are. Why can't dragon-egg live in both places and be re-merged regularly? It is in a rather odd position of straddling two projects. If the FSF gcc developers want to keep dragonegg over in LLVM's repository only, at least the discussion might tweak the curiosity of a few gcc developers. Jack
On Fri, Apr 9, 2010 at 9:30 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:> On Fri, Apr 09, 2010 at 05:22:17PM +0200, Duncan Sands wrote: >> Hi Jack, >> >>>>> Is there a timeline for when dragonegg might be >>>>> merged into gcc (4.6 perhaps)? I ask because FSF gcc >>>>> has allowed code in as technology previews before. >>>>> For instance, graphite really wasn't that usable in >>>>> gcc 4.4 and produced wrong code in the Polyhedron >>>>> 2005 benchmarks until gcc 4.5. So as long as it can bootstrap >>>>> gcc 4.6 and works in general, dragonegg should qualify >>>>> for inclusion as an experimental plugin. >>>> >>>> I hadn't really thought about adding dragonegg to the gcc codebase. >>>> What do you see as the advantages of doing so? >> >>> I thought that gcc plug-ins were meant to become part of >>> the FSF gcc source code, no? In any case, if dragonegg were >>> in the FSF gcc source code, it would have much higher >>> visibility and a better chance that some of the existing >>> FSF gcc developers would tinker with it on the side. >> >> another advantage of having plugins in the gcc repository is that when a gcc >> developer makes an API change they will (hopefully) fix the plugin as well as >> the rest of the code. On the other hand, there's the same advantage to being >> in the LLVM repository: LLVM developers will (hopefully) fix dragonegg when >> they make an API change, though it has to be said that Chris broke dragonegg >> several times recently but didn't notice :) LLVM is changing far more than >> gcc as far as dragonegg is concerned, suggesting that the LLVM repository is >> a better place to live. >> >> As for visibility, you are probably right that many more people would become >> aware of dragonegg if it was part of gcc. I'm not sure that that's a real >> argument though, because a good "advertising campaign" would probably be much >> more effective as far as visibility is concerned than including dragonegg in >> the gcc repository. As for gcc developers tinkering with it - well, indeed >> they might, who can say? Dragonegg does already get a small amount of gcc >> visibility already, since I submit gcc patches for dragonegg issues from time >> to time, but as far as I know no gcc developers ever tried it. >> >> Ciao, >> >> Duncan. > > Duncan, > I'll broach the topic on gcc at gcc.gnu.org and see what the > responses are. Why can't dragon-egg live in both places and > be re-merged regularly?Re-merging it regularly sounds like it would require extra work beyond what Duncan's already doing to maintain it. Please don't suggest other people do extra work unless you're also offering to do it for them.
On Apr 9, 2010, at 10:11 AM, Jeffrey Yasskin wrote:>> >> Duncan, >> I'll broach the topic on gcc at gcc.gnu.org and see what the >> responses are. Why can't dragon-egg live in both places and >> be re-merged regularly? > > Re-merging it regularly sounds like it would require extra work beyond > what Duncan's already doing to maintain it. Please don't suggest other > people do extra work unless you're also offering to do it for them.Random thought: If the GCC community is actually interested in this, it would probably make sense for the gcc tree to have a version of dragonegg that worked with the last released version of llvm, not for it to try to chase tot. The LLVM tree would have a version of dragonegg that chased llvm ToT but worked with hte last released version of gcc. Of course, this would depend on someone being willing to do the work :) -Chris
On Fri, Apr 09, 2010 at 10:11:15AM -0700, Jeffrey Yasskin wrote:> On Fri, Apr 9, 2010 at 9:30 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > > On Fri, Apr 09, 2010 at 05:22:17PM +0200, Duncan Sands wrote: > >> Hi Jack, > >> > >>>>> Is there a timeline for when dragonegg might be > >>>>> merged into gcc (4.6 perhaps)? I ask because FSF gcc > >>>>> has allowed code in as technology previews before. > >>>>> For instance, graphite really wasn't that usable in > >>>>> gcc 4.4 and produced wrong code in the Polyhedron > >>>>> 2005 benchmarks until gcc 4.5. So as long as it can bootstrap > >>>>> gcc 4.6 and works in general, dragonegg should qualify > >>>>> for inclusion as an experimental plugin. > >>>> > >>>> I hadn't really thought about adding dragonegg to the gcc codebase. > >>>> What do you see as the advantages of doing so? > >> > >>> I thought that gcc plug-ins were meant to become part of > >>> the FSF gcc source code, no? In any case, if dragonegg were > >>> in the FSF gcc source code, it would have much higher > >>> visibility and a better chance that some of the existing > >>> FSF gcc developers would tinker with it on the side. > >> > >> another advantage of having plugins in the gcc repository is that when a gcc > >> developer makes an API change they will (hopefully) fix the plugin as well as > >> the rest of the code. On the other hand, there's the same advantage to being > >> in the LLVM repository: LLVM developers will (hopefully) fix dragonegg when > >> they make an API change, though it has to be said that Chris broke dragonegg > >> several times recently but didn't notice :) LLVM is changing far more than > >> gcc as far as dragonegg is concerned, suggesting that the LLVM repository is > >> a better place to live. > >> > >> As for visibility, you are probably right that many more people would become > >> aware of dragonegg if it was part of gcc. I'm not sure that that's a real > >> argument though, because a good "advertising campaign" would probably be much > >> more effective as far as visibility is concerned than including dragonegg in > >> the gcc repository. As for gcc developers tinkering with it - well, indeed > >> they might, who can say? Dragonegg does already get a small amount of gcc > >> visibility already, since I submit gcc patches for dragonegg issues from time > >> to time, but as far as I know no gcc developers ever tried it. > >> > >> Ciao, > >> > >> Duncan. > > > > Duncan, > > I'll broach the topic on gcc at gcc.gnu.org and see what the > > responses are. Why can't dragon-egg live in both places and > > be re-merged regularly? > > Re-merging it regularly sounds like it would require extra work beyond > what Duncan's already doing to maintain it. Please don't suggest other > people do extra work unless you're also offering to do it for them.Jeffrey, I didn't intend to cause problems but just start a general discussion on both sides of the merits of including dragonegg in the FSF gcc source tree. With regard to re-merging, wouldn't allowing the two repositories of dragonegg to fork for too long cause just as much work as periodic remerges? Jack