--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 43404
(In reply to Richard Biener from comment #6)
> (In reply to Tom de Vries from comment #4)
> > (In reply to rguent...@suse.de from comment #3)
> > > This is the usual "you should not repeat analysis during transform" issue.
> > > The vectorizer gets around this by caching relevant scalar evolution
> > > but obviously that's difficult if using generic stuff like
> > > canonicalize_loop_ivs ...
> > I wonder if it makes sense to add an interface to scalar_evolution_info to
> > update the instantiated_below field for existing entries. So, before the
> > loop versioning, the loop preheader is bb10, but after loop versioning, it's
> > bb15. If we update the instantiated_below field from 10 to 15, the cached
> > scalar evolution info can still be used.
> I don't see how this is a sound API that can be used without too much
> possibility to shoot yourself in the foot ;)
I suppose, yes. Anyway, out of curiosity, I made this demonstrator patch that
fixes the problem using such an API.
> I _think_ that eventually the bug is fixed if you move the update_ssa after
> versioning to after canonicalize_loop_ivs which should have a similar effect
> than what you propose. GRAPHITE relies on defered update_ssa as well to
> maintain "compatible" SCEV analysis results.
I think that indeed is necessary, but not sufficient by itself. Postponing
update_ssa doesn't fix the fact that the instantiated_below bb has changed
(which is the bit that this patch tries to fix).