GCC 3.3 compile speed regression - AN ANSWER

[Richard Henderson]

On Tue, Feb 11, 2003 at 04:08:53PM -0800, Linus Torvalds wrote:
> 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.

Indeed.  Or replace old brute-force passes with ones that
use better algorithms.

> 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.

I agree.  One of the reasons why I think Neil's making a mistake
not generating trees right off the bat.

> 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.

You need to go to rtl (or some other low-level format) for scheduling
and register allocation.  That is the point at which your intermediate
language ideally should be in 1-1 correspondence with the assembly.
I'd bet there isn't a single commercial compiler that doesn't do this.

In our case, we'd want to go there before combine, since it's combine's
job to munge several "simple" insns into some cisc-y thing.


r~