Re: GCC 3.3 compile speed regression - AN ANSWER

[Linus Torvalds <torvalds at transmeta dot com>]

In article <Pine.LNX.4.33.0302112331070.27761-100000@kern.srcf.societies.cam.ac.uk> you write:
>On Tue, 11 Feb 2003, Michael S. Zick wrote:
>
>> 1) Give the problem/solution the recognition it deserves in the form of
>> a separate branch, solely for this specific purpose.
>
>We *have* the faster-compiler-branch, created at the same time as
>gcc-3_4-basic-improvements-branch
><http://gcc.gnu.org/ml/gcc/2002-08/msg01575.html>.  It just hasn't been
>used, whereas BIB was extensively used.

I bet the reason it didn't get used is simply that making the compile
faster is a hell of a lot harder than just adding a few improvements.

The thing is, if you want to make gcc faster, you have to bite the
bullet and throw out code that doesn't perform well.  And you have to
_remove_ phases of optimization, instead of adding new ones.  Having
different phases where you operate on different kinds of data structures
(ie tree -> ssa -> rtl) is just fundamentally slow, as you have to
marshall the data into the right format for the next phase (which is
likely bad for caches too). 

And I don't think anybody is really interested enough to do it. And as
long as it doesn't get done, the rest of the performance improvements
are going to be completely hidden in the noise.

The CPP rewrite is a good example of better performance by just getting
rid of code, not by massaging it. Make the thing more integrated, so
that the next "phase" of the compiler can use the data structures
in-place.

I bet that people working on the recursive-descent parser will get quite
noticeable speeups, _especially_ if the parser can build up the parse
tree in a format where the tree is directly usable for the tree
optimization phase and doesn't need any more munging.

Then the next step would likely be to jump over the SSA and RTL phases,
and generate code directly from the same tree-based thing.  That's how
most historical compilers used to work, afaik. For well-written C, you
don't need much else anyway.

			Linus