[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