RE: dragonegg in FSF gcc?

["Grigori Fursin" <gfursin@gmail.com>]

Hello,

Hope my question will not completely divert the topic of this discussion -
just curious what do you mean by better code? Better execution time, code size, 
compilation time?..

If yes, then why not to compare different compilers by just compiling multiple programs
with GCC, LLVM, Open64, ICC, etc, separately to compare those characteristics and then 
find missing optimizations or better combinations of optimizations to achieve the result? 

By the way, using iterative feedback-directed compilation (searching for best combinations 
of optimizations) can considerably improve default optimization heuristic of nearly any 
compiler (look at ACOVEA or cTuning.org results) so it may not be so straightforward
to answer a question which compiler is better when just using default optimization heuristic ...

Cheers,
Grigori

*************************************************************
Grigori Fursin, Exascale Research Center, France
http://unidapt.org/people/gfursin
*************************************************************




-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of Duncan Sands
Sent: Sunday, April 11, 2010 5:36 PM
To: Eric Botcazou
Cc: gcc@gcc.gnu.org; Steven Bosscher
Subject: Re: dragonegg in FSF gcc?

Hi Eric,

>> 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.
>
> Well, the last point is very likely precisely what Steven is talking about.
> GCC doesn't have to shoot itself in the foot by encouraging its developers to
> migrate to LLVM.

I hope it was clear from my email that by "gcc" I was talking about the gcc
optimizers and code generators and not the gcc frontends.  If the dragonegg
project shows that feeding the output of the gcc frontends into the LLVM
optimizers and code generators results in better code, then gcc can always
change to using the LLVM optimizers and code generators, resulting in a better
compiler.  I don't see how this is gcc the compiler shooting itself in the foot.

Of course, some gcc devs have invested a lot in the gcc middle and back ends,
and moving to LLVM might be personally costly for them.  Thus they might be
shooting themselves in the foot by helping the LLVM project, but this should
not be confused with gcc the compiler shooting itself in the foot.

All this is predicated on gcc-frontends+LLVM producing better code than the
current gcc-frontends+gcc-middle/backends.  As I mentioned, dragonegg makes
it easier, even trivial, to test this.  So those who think that LLVM is all
hype should be cheering on the dragonegg project, because now they have a
great way to prove that gcc does a better job!

Ciao,

Duncan.