Huge compile time regressions

[Joern RENNECKE]

Daniel Berlin wrote:

>On Thu, 2005-12-15 at 00:48 +0100, Steven Bosscher wrote:
>  
>
>>Hi,
>>
>>Someone caused a >10% compile time regression yesterday for CSiBE, see
>>http://www.csibe.org/draw-diag.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish&draw=sbs&view=1&basephp=l-sbs
>>
>>
>>Gr.
>>Steven
>>
>>    
>>
>
>This is very very bad.
>
>Joern, i'd imagine this was your patch.
>  
>
I think this is related to using register liveness information from 
flow.  My original if-conversion patch 
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03281.html used a simple 
linear-time
algorithm to identify registers that are local to each basic block.

I can think of two things that could cause a noticable slowdown:

- comparison of global_live_at_end in struct_equiv_init.  Most call 
sites call gcc_unreachable when struct_equiv_init fails.  If an 
additional parameter is passed into struct_equiv_init  to tell if the 
the comparison may fail, we can optimize the sanity check out for 
!ENABLE_CHECKING.
- The call to update_life_info_in_dirty_blocks when one of the compared 
blocks is dirty.  I'm not sure if we could get away with doing a local 
update, and/or starting the update only for the blocks under 
consideration.  If we don't have to do the global_live_at_end 
comparison, we can probably also skip the update if only one of the 
blocks is dirty, and use the global_live_at_end from the block that is 
not dirty.

A further improvement might be to remove the regset comparison from 
struct_equiv_init altogether, and only make sure we use a 
global_live_at_end that is right for at least one of the
blocks.  The regsets can be compared later when we have matched all the 
edges, maybe even the entire block.

We could also go back to makling sure we have consistent data flow 
information at the start of the pass, and keep the bits that we need 
up-to-date as we go along.