[patch] Update loops in cfg manipulation functions

[Zdenek Dvorak]

Hello,

> Zdenek Dvorak wrote on 10/23/06 04:53:
> 
> >*************** execute_vrp (void)
> >*** 4781,4787 ****
> >  {
> >    insert_range_assertions ();
> >  
> >!   current_loops = loop_optimizer_init (LOOPS_NORMAL);
> >    if (current_loops)
> >      scev_initialize (current_loops);
> >  
> >--- 4781,4787 ----
> >  {
> >    insert_range_assertions ();
> >  
> >!   loop_optimizer_init (LOOPS_NORMAL);
> >    if (current_loops)
> >      scev_initialize (current_loops);
> >  
> If we are going to be keeping loops up-to-date, wouldn't this
> initialization be unnecessary?  Couldn't we just initialize loops
> after the CFG is built?  If not, would it make sense to have that as a
> long-term goal?

see http://gcc.gnu.org/wiki/PreservingLoops

> >  #define avail_temp_slots (cfun->x_avail_temp_slots)
> >  #define temp_slot_level (cfun->x_temp_slot_level)
> >  #define nonlocal_goto_handler_labels 
> >  (cfun->x_nonlocal_goto_handler_labels)
> >+ #define current_loops (cfun->x_current_loops)
> >  
> For now I guess this is OK, but I would really prefer that we had CFUN
> a parameter to this accessor.  Since Jan is working in this area, we
> can do this afterwards.
> 
> 
> Nice cleanup.  Thanks.  Any idea on compile-time impact?  We seem to
> be doing more in the CFG low-level manipulators.

I did not measure any change on compiling preprocessed gcc sources (we
usually do not spend much time in cfg manipulations).

Zdenek

> The patch crosses into the middle-end quite a bit, I'd like a
> middle-end maintainer to look at it as well.