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

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

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

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


SimplifyIndVar generally only works on direct users of the IV, including for icmp simplification. In this case there's a trunc between the IV and the icmp, so we don't try to simplify.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63618