[PATCH] D67178: [SCEV] Use loop guard info when computing the max BE taken count in howFarToZero.

[Florian Hahn via Phabricator via llvm-commits]

fhahn added a comment.

In D67178#1658602 <https://reviews.llvm.org/D67178#1658602>, @efriedma wrote:

> In terms of general API, I don't think we want to expose "applyLoopGuards"; the SCEV transform proposed here isn't really useful outside of trying to find the minimum or maximum, as far as I can tell.   Which min/max expressions we want to form depends on whether we're computing a "max" or a "min".  And restricting the API so the point in the CFG we're querying has to be a loop header doesn't seem helpful; other places might care about values after a loop etc.
>
> In terms of the implementation, this composes well, in a sense: it annotates the relevant SCEV expressions with the relevant conditions, then uses the general implementation that ignores control flow.  But I'm not sure how it scales for larger SCEV expressions; keeping a map on the side seems like it would have more predictable performance.


Yeah, duplicating a whole expression just because we want to attach additional range information could lead to poor performance for large expressions. I'll look into the map approach.

> I don't really have a general vision for what the range computation implementation should look like in the future: what sources of information are practical to use?  What overall data structure do we use to integrate them?

Do you mean in general or in for SCEV?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67178