[PATCH] D100004: [SCEV] Correct handling of recurrences matched in partially unreachable code (try 2)

Max Kazantsev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 19 08:35:18 PDT 2021


mkazantsev added inline comments.


================
Comment at: llvm/lib/Analysis/ScalarEvolution.cpp:5675
   auto *L = LI.getLoopFor(P->getParent());
-  assert(L && L->getHeader() == P->getParent());
-  if (!L->contains(BO->getParent()))
+  if (!L || L->getHeader() != P->getParent())
+    // If we have unreachable blocks involved, then dominance collapses and
----------------
reames wrote:
> mkazantsev wrote:
> > reames wrote:
> > > mkazantsev wrote:
> > > > Do we have a guarantee of having no loops in unreachable code?
> > > See LoopInfoBase<>::analyze specififically the line:
> > > DomTree.isReachableFromEntry(Backedge))
> > > 
> > > Note that the verify routine also checks against a newly constructed LI, so any failure to update should be caught in a expensive asserts run.
> > But expensive verification runs between the passes. It is still possible that some pass makes a loop unreachable in the middle of the transform and does not immediately destroy the loop while continuing to use SCEV.
> > 
> > I am still strongly leaning towards not relying on such things, even if they might be correct. It's far from obvious and far from simple.
> Passes that rely on running with partially corrupt analyzes are buggy.  We should find and fix them.
It is not a corrupt analysis. It is clearly stated that LI for unreachable blocks is undefined. It may have loops anywhere.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100004/new/

https://reviews.llvm.org/D100004



More information about the llvm-commits mailing list