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-ow...@gcc.gnu.org [mailto:gcc-ow...@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.
