calculate_global_regs_live

[Eric Botcazou]

> I tried looking at callers of update_life_info.  It looks like most of
> them already pass all blocks when extent != UPDATE_LIFE_LOCAL.
> Exceptions:
>   cfgrtl.c purge_all_dead_edges
>   recog.c split_all_insns
>   sched-rgn.c schedule_insns

Yes, I did the same search.

> Since the majority already do this, I suspect the run time performance
> won't be impacted too much if we assume this.

I don't know (but of course I don't have your experience).  There is perhaps 
a trade-off here, because infinite loops in c_g_r_l appear to be very rare.  
And we could make them even rarer by clearing the BBs in 'blocks'.

> There is a particularly interesting bit in flow.c in the function
> update_life_info_in_dirty_blocks.  If called with a subset of blocks,
> and extent is not UPDATE_LIFE_LOCAL, then it already adds in all
> blocks.  There is a comment that says this was needed to fix a pentium4
> bootstrap failure.  So again, it seems someone ran into a related
> problem.  And not surprisingly, it was Richard Henderson again.  See
> 	http://gcc.gnu.org/ml/gcc-patches/2002-05/msg02253.html

Oh! yes, the very same problem.  Could you lend me your glasses (or your eyes 
if you prefer)? :-)

> This message refers to suggestions from Jan to solve the problem you are
> looking into.  Maybe you can find them on the mailing list archive?  Or
> maybe Jan remembers?

Jan, do you have any recollection about suggestions to guarantee that 
calculate_global_regs_live from flow.c will always terminate?

The problem is described here:
   http://gcc.gnu.org/ml/gcc/2003-12/msg00698.html
It was also reported here:
   http://gcc.gnu.org/ml/gcc/2001-02/msg00476.html
And Richard hinted at your suggestions here:
   http://gcc.gnu.org/ml/gcc-patches/2002-05/msg02253.html

-- 
Eric Botcazou