Ian Lance Taylor wrote:
These charts are certainly discouraging. On the other hand, for some
real code we're seeing each new version of gcc produce an incremental
runtime improvement. So I'm not sure what to make of it.
This is hardly a new thought, but I believe that for the i386 gcc is
handicapped by reload. No matter how smart we are before reload, it
just take one poor decision by reload in an inner loop and we've lost
all the gains. Reload has enormous complexities which are mostly
irrelevant for the i386. And I think that the idea of doing register
allocation separately from spill code generation does not make sense
on the i386.
I would agree if we were talking about all gcc register allocation. All
gcc register allocation is really bad. But there are different spills.
Ones are because of the register pressure and another ones are because
of the insn operand constraint combination. The both can be taken into
account before the reload in some acceptable way.
That is what impression I got from implementation of a register
allocation without the reload for x86 and x86_64 and one with the
reload. You can get the same improvement for x86.
As for x86_64 I found that spilling because register pressure is not so
high right now (at least for x86_64 and for SPEC2000 because it has
exactly in 2.5 more times more integer registers). Therefore I
mentioned about putting more values on the registers. I hope LTO will
help in that way too.
Reload is a mess but in local context it is doing a good job. It was
refined for many years and conceptually it is not so difficult to
understand. Removing it is not a rewarding job probably. May be we
need just to improve it and have a better documentation.
I don't think gcc has hit any sort of wall, except insofar as we have
no plan for eliminating reload. I don't think portability comes into
play here.
That said, I certainly agree that we should try to figure out what is
going on as much as possible.
I also want to say that at present LTO is a collection of different
projects. Most of them are aimed directly at speeding up the
compiler, reducing compile time. So far nobody is working on any
changes to the actual optimization framework. So I'm not too
concerned yet about LTO in this context. I certainly agree that when
LTO moves into an optimization phase, we need to make sure that any
default passes pay off in terms of compilation time or runtime
performance.
I am agree that LTO is the next big project which could help gcc in many
way. And we need to do this to keep gcc in pace with other compilers
(mostly Intel).
