GCC 3.3 compile speed regression

[Nathanael Nerode]

 >On Tue, 11 Feb 2003, Matt Austern wrote:
 >
 >> All of my measurements suggest that improving the speed of 
 >>optimization
 >> phases is irrelevant.  What's slow is the front end: parsing and
 >> semantic analysis.  -O0 compilations are slow, not just -O3.

 >The -fsyntax-only figures posted
 ><http://gcc.gnu.org/ml/gcc/2003-02/msg00488.html> show it is not the 
 >front
 >end; -O0 -fsyntax-only has become faster, while the time for >unoptimized
 >code generation (the time for -O0 minus that for -O0 -fsyntax-only) has
 >doubled between 2.95 branch and mainline and the times to optimize have
 >become worse as well.  (This is for the C front end.)  (In absolute 
 >terms,
 >the front end may still count as slow, but not if what you're comparing
 >with is GCC 2.95.)
 >
 >--
 >Joseph S. Myers

There's a closely related problem which I've hit every time I try to 
debug a 'blow-up' in compilation time, and I believe this is the true 
source of slowdowns at -O0.  A lot of stuff is being computed -- *even 
at -O0* -- which is only used for optimization passes.  This is simply 
wrong behavior.  Data which is only used for optimization should not be 
computed at -O0, since it just gets thrown away anyway.

I can't remember the exact examples right now.  But the upcoming cleanup 
of toplev.c should make these cases a lot more obvious. :-/

--Nathanael