Duncan Sands wrote:
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.
I've tried to compare gcc4.5 and dragonegg a week ago on SPEC2000 on
a Core I7.
Here are some results.
Only SPECIn2000 for x86_64 has been compiled fully successfully by
dragonegg. There were a few compiler crashes including some in LLVM
itself for SPECFP2000 and for SPECINT2000 for x86.
So here is SPECInt2000 for x86_64 comparison:
dragonegg: -O3 (with LLVM release build)
gcc4.5: -O3 -flto (--enable-checking=release)
Compilation Time SPECINT2000
Dragonegg 122.85user 2572
gcc-4.5 283.49user 2841
On integer benchmarks, dragonegg generates about 11% slower code.
One interesting thing is that dragonegg is a really fast compiler. It
is 2.3 times faster than gcc.