[LLVMdev] dragonegg FSF gcc merge?

[Jack Howarth]

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