Robert Dewar wrote:
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.
For me definitely. Also as I wrote I would not be too much worried
about it. GCC looks good in comparison with other industrial compiler
with compile time (and code size too) point of view. Here I mean Intel,
SunStudio, PathScale, Open64 ones.
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.
I am agree with this for moderately optimizing compilers. But for
highly optimizing compilers it might be no true. Intel generates much
better and bigger code than gcc. Although it might be mostly because of
code versioning (including one for different subtargets).
