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

Thu Apr 26 14:50:45 PDT 2018

hfinkel added a comment.

In https://reviews.llvm.org/D44677#1080078, @sanjoy wrote:

> > 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).

I think the invariant here has to be that, so long as you don't change the trip count, you don't need to invalidate it in SE. "When it has changed a loop in a way that may effect ScalarEvolution's ability to compute a trip count" is an impossible contract to keep, except in the most conservative sense. How could the client know exactly how powerful SE's analysis capabilities are such that it would know whether it has done something that would affect SE's ability to compute the trip count? How should the client know which IR values SE is relying on to compute the trip count?

Repository:
  rL LLVM

https://reviews.llvm.org/D44677