This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dragonegg in FSF gcc?

Hi Steven,

I think Jack wasn't suggesting that dragonegg should be changed to not be
a plugin any more.  I think he was suggesting that it should live in the gcc
repository rather than the LLVM repository.

So, no offense, but the suggestion here is to make this subversive (for FSF GCC) plugin part of FSF GCC? What is the benefit of this for GCC? I don't see any. I just see a plugin trying to piggy-back on the hard work of GCC front-end developers and negating the efforts of those working on the middle ends and back ends.

I'm sorry you see the dragonegg project so negatively. I think it is useful for gcc (though not hugely useful), since it makes it easy to compare the gcc and LLVM optimizers and code generators, not to mention the gcc and LLVM approaches to LTO. If LLVM manages to produce better code than gcc for some testcase, then it is a convenient tool for the gcc devs to find out why, and improve gcc. If gcc is consistently better than LLVM then there's nothing to worry about! Of course, right now it is LLVM that is mostly playing catchup with gcc, so for the moment it is principally the LLVM devs that get to learn from gcc, but as LLVM improves the other direction is likely to occur more often.

As for "negating the efforts of those working on the middle ends and back ends",
would you complain if someone came up with a new register allocator because it
negates the efforts of those who work on the old one?  If LLVM is technically
superior, then that's a fact and a good thing, not subversion, and hopefully
will encourage the gcc devs to either improve gcc or migrate to LLVM.  If GCC
is technically superior, then hopefully the dragonegg project will help people
see this, by making it easier to compare the two technologies, and result in
them giving up on LLVM and working on or using gcc instead.

In my opinion a bit of friendly competition from LLVM is on the whole a good
thing for gcc.

That said, maybe your worry is that dragonegg makes it easier to undermine the
GPL, or perhaps you don't like LLVM's BSD style license?  I really have no
understanding of the legal issues involved with "undermining the GPL", but I
know that some of the gcc devs have thought hard about this so perhaps they can
comment.  I'm personally not at all interested in undermining the GPL.  As for
licenses, the dragonegg plugin, as a combined work of GPLv3 code (gcc), GPLv2
or later (the plugin) and GPL compatible code (LLVM), is as far as I can see
GPLv3 and as such no different to gcc itself.

Finally, I don't see much point in dragonegg being moved to the gcc repository.
It wasn't I who suggested it.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]