[LLVMdev] dragonegg FSF gcc merge?

Jeffrey Yasskin jyasskin at google.com
Fri Apr 9 10:11:15 PDT 2010


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.




More information about the llvm-dev mailing list