On Fri, Apr 09, 2010 at 04:14: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? > > Ciao, > > Duncan.Duncan, 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. Jack> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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.
> 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.>From the discussions I have heard GCC plugins will not be maintained if the APIchanges. It is up to the developer of the plugin to make sure it works. Some code may migrate from being a plugin to being a permanent component (if it is important enough) and will then be fixed if the API changes. - Jan
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