Vladimir Makarov wrote:
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.
Actually for my taste, you have to get a MUCH bigger factor in compile
time before you can call yourself a fast compiler (Realia COBOL by
comparison compiles millions of lines a minute of code on current
PC's, using just one core). GCC has taken a decision to favor
performance of the code absolutely over compiler performance.
That's not such a bad bet given how fast machines are getting.
So I think this compile time advantage is not that interesting.
Draggonegg generates smaller text sections but bigger data sections.
Unfortunately, my scripts measure and compare only text sections. Therefore
I am not posting this text code size comparison because it has no
sense. But looking
at small benchmarks, I got an impression that gcc generates smaller code
(text + data)
in general than dragonegg.
Usually you will find that to a first order approximation, speed and
size are linearly related.
