[PATCH] D63618: Exploit a zero LoopExit count to eliminate loop exits

[Philip Reames via Phabricator via llvm-commits]

reames added a comment.

In D63618#1553053 <https://reviews.llvm.org/D63618#1553053>, @sanjoy wrote:

> > it seems like there are a lot of cases where SCEV's exit count reasoning is stronger than it's isKnownPredicate reasoning.
>
> This is somewhat surprising.  For instance in `@test_06` I would have expected SCEV to compute the range of `%narrow.iv` to be `[INT32_MAX, INT32_MAX+1)` (using the fact that the backedge taken count is 0), and thus figure resolve the `icmp slt` to `false` by just looking at the ranges.  Any idea why that's not happening?


I haven't looked into that one specifically, but in general, I've been noticing a *lot* of issues with caching and computation of overflow bits.  I've now seen several cases where we form a SCEV, then later figure out one component of it is nsw/nuw, but don't simplify the previously formed SCEV.  Since we rely on equality in many cases for equivalence checks, that means we fail to prove things which appear obvious.  Usually, a second run on indvars (after flags are set in IR) gets these cases.

Also, there is an argument that exit count reasoning "should" be more powerful than the predicate based form.  When we're analysing a compare *knowing it controls an exit* we do have slightly more information than in the general predicate reasoning.  (Consider a loop with one unanalysable exit and thus no exact BE count for the loop as a whole..)


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63618