cache misses in gcc 3.3

[Andi Kleen]

> One thing that is really important in going after speed improvements is
> to have really accurate profiling information that shows where the time
> is being spent. Otherwise you will chase phantoms.

My -O2 test case was spending 10% in the parser, according to the standard timing
output. This was in the top three, with only CSE being slower. This was on an
Athlon.

The explanation offered by cachegrind - excessive data cache misses when accessing
the bison parser state tables - didn't look too unreasonable.

Interestingly I tried it on a P4 too and there the parser took upto 15%.
Perhaps it suffers from poor branch predicton or similar.

As far as I can see Neil is doing a good thing by attacking the C parser.
Hopefully CSE can be fixed too - I assume tree-ssa will do that eventually?

-Andi