[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