dragonegg FSF gcc merge?

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.
                Jack

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.

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

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 :slight_smile: 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 :slight_smile: 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 API

changes. 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

Duncan,
   I'll broach the topic on gcc@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

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 :slight_smile:

-Chris

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

>>
>> Duncan,
>> I'll broach the topic on gcc@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.

This certainly makes sense. The llvm repository dragonegg would be built
against the current release of FSF gcc and the development version of llvm
while the FSF gcc repository dragonegg would be built against the development
gcc version and the current release of llvm. Upon either a llvm or FSF gcc
release, the two repositories would merge.

Of course, this would depend on someone being willing to do the work :slight_smile:

I would try to be an optimist (that llvm represents enough value to drive
the dragonegg development once folks are exposed to it).
                 Jack