[LLVMdev] dragonegg FSF gcc merge?
howarth at bromo.med.uc.edu
Fri Apr 9 09:30:05 PDT 2010
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.
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.
More information about the llvm-dev