https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83126
--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> --- Created attachment 43404 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43404&action=edit Demonstrator patch (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).
