Re: GCC 3.3 compile speed regression

[Nathanael Nerode <neroden at twcny dot rr dot com>]

>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