[PATCH] D144050: [SCEV] Strengthen nowrap flags via ranges for ARs on construction.

[Max Kazantsev via Phabricator via llvm-commits]

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

LG



================
Comment at: llvm/test/Analysis/ScalarEvolution/incorrect-exit-count.ll:20
 ; CHECK-NEXT:    %storemerge1921 = phi i32 [ 3, %outer.loop ], [ %dec, %for.end ]
-; CHECK-NEXT:    --> {3,+,-1}<nuw><nsw><%for.cond6> U: [3,4) S: [3,4) Exits: <<Unknown>> LoopDispositions: { %for.cond6: Computable, %outer.loop: Variant }
+; CHECK-NEXT:    --> {3,+,-1}<nsw><%for.cond6> U: [3,4) S: [3,4) Exits: <<Unknown>> LoopDispositions: { %for.cond6: Computable, %outer.loop: Variant }
 ; CHECK-NEXT:    %idxprom20 = zext i32 %storemerge1921 to i64
----------------
fhahn wrote:
> fhahn wrote:
> > nikic wrote:
> > > Regression
> > I still need to investigate this one.
> Ok, here's what's going on.
> 
> Without this patch, this is strengthened by this code here:
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/Analysis/ScalarEvolution.cpp#L1651
> 
> With the new changes, this code now gets called earlier via the call to `proveNoWrapViaConstantRanges`, which in turn computes the backedge taken-count, which in turn calls `getSCEVAtScope`, which in turn creates the SCEV for `%idxprom20`. Because `getSCEVAtScope` constructs the SCEV for `%idxprom20` while computing the backedge taken count, the backedge taken count will be `SCEVCouldNotCompute` at L1651, hence the flags don't get strengthened.
> 
> I don't know if there's a way to avoid this issue, but it seems a small price to pay in this case. 
Interesting. If we have proved that the range here only contains `3`, can we just reduce it to `SCEVConstant`?

I believe that if a loop has zero BE taken count, all its AddRecs are `<nuw><nsw>` too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144050