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.
