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

Fri Jun 21 11:10:28 PDT 2019

sanjoy accepted this revision.
sanjoy added a comment.
This revision is now accepted and ready to land.

In D63618#1553926 <https://reviews.llvm.org/D63618#1553926>, @reames wrote:

> 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,

SCEV seems to compute the correct range for that specific case:

  %narrow.iv = trunc i64 %iv to i32
  -->  {2147483647,+,1}<%loop> U: [2147483647,-2147483648) S: [2147483647,-2147483648)          Exits: 2147483647               LoopDispositions: { %loop: Computable }

so the comparison should be folded based on constant range analysis alone.  Do you mind spot checking if indvars is even _trying_ to fold the condition correctly?

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

Having proper use lists for SCEV might help.  That would let us simplify users of a SCEV in a simplified manner once a SCEV has been proven not to wrap.

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

Agreed.  I'm mainly curious about the specific test changes in this patch, not with the general idea.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63618