[PATCH] Fix PR36078, fallout from early loop unrolling

Richard Guenther rguenther@suse.de
Tue Apr 29 16:52:00 GMT 2008


On Tue, 29 Apr 2008, Zdenek Dvorak wrote:

> Hi,
> 
> > > A nicer fix would be to make cfg cleanup preserve ssa form for virtual
> > > ops.  In theory, this is easy -- the phi node elimination should only
> > > make the memory addresses more specific, thus it may only make some of
> > > the vops disappear, in which case we can just "copy propagate" them.  In
> > > practice, alias analysis somehow manages (or at least, used to manage)
> > > to introduce new vops, thus making this impossible.
> > 
> > Ok, so with the unrolling code that does
> > 
> >   do
> >     {
> >       changed = false;
> > 
> >       FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
> > ...
> >           changed |= canonicalize_loop_induction_variables...
> > ...
> >       if (changed)
> >         {
> >           /* This will take care of removing completely unrolled loops
> >              from the loop structures so we can continue unrolling now
> >              innermost loops.  */
> >           cleanup_tree_cfg ();
> > 
> >           /* Clean up the information about numbers of iterations, since
> >              complete unrolling might have invalidated it.  */
> >           scev_reset ();
> >         }
> >     }
> >   while (changed);
> > 
> > that is, iterates until one iteration didn't result in more unrolling
> > (but cleans up the CFG before to enable new unrolling), the patch I
> > proposed is indeed reasonable.  Correct?
> 
> I would propose instead changing the code to
> 
> if (cleanup_tree_cfg ())
>   update_ssa (TODO_update_ssa_only_virtuals);
> 
> (it would make me a bit nervous to proceed with possibly invalid ssa for
> vops, although I do not see a concrete problem that this could cause).

Ok, I'll test the above change.

Thanks,
Richard.



More information about the Gcc-patches mailing list