[PATCH] D44677: [SCEV] Make computeExitLimit more simple and more powerful

Sanjoy Das via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 26 14:10:37 PDT 2018


sanjoy added a comment.

> computeExitLimit's logic shouldn't care if the exiting block is inside a nested loop, as long as the condition is invariant relative to the inner loop. (This should work correctly, as far as I can tell; if it doesn't, it would be easy to fix.) So the question is if there's some invariant related to the caching?

Agreed -- I too was thinking of a caching invariant.  For instance, maybe there is some invariant which lets us avoid caching blocks from child loops in parent's `BackedgeTakenInfo` instances and effectively treats child loops as black boxes.

> The comment for forgetLoop says "This method should be called by the client when it has changed a loop in a way that may effect ScalarEvolution's ability to compute a trip count". We could try to restrict this, bit I'm not sure what restriction would actually be useful. I can't imagine any formulation which doesn't require calling forgetLoop when a branch that exits that loop is added/removed/modified.

The kind of invariant I had in mind was as long as you don't change the *trip count* of a loop, its parents do not need to be invalidated.  So unrolling or rotating a loop needs to invalidate its parent (but not its grandparent).


Repository:
  rL LLVM

https://reviews.llvm.org/D44677





More information about the llvm-commits mailing list