[PATCH] D133020: [LAA] Fix ICE with scAddExpr in forked pointers

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 1 14:04:24 PDT 2022


fhahn added inline comments.


================
Comment at: llvm/test/Analysis/LoopAccessAnalysis/forked-pointers.ll:899
+; CHECK-NEXT:       Group [[G2]]:
+; CHECK-NEXT:         (Low: %0 High: %0)
+; CHECK-NEXT:           Member: {%0,+,8}<%for.body.us>
----------------
huntergr wrote:
> fhahn wrote:
> > huntergr wrote:
> > > This concerns me a bit -- the lower bound is correct, but the upper bound seems wrong. But that isn't related to my forked pointers patch -- I get the same output if I comment out the forked pointer detection code entirely.
> > This is probably because PSE a predicate for this. The loop has an IV that start at 0 and we only exit if `iv == 0`. This can only happen if `iv` overflows AFAICT. But the IV increment is ` add nuw nsw i64 %indvars.iv.us1, 1`, so if it overflows it is UB.
> > 
> > Can the issue be reproduced with a loop that doesn't have UB, e.g. replacing the existing exit check with something like `cmp eq i64 %indvars.iv.next.us,  %N`?
> You're right, thanks. I see `(Low: %Base2 High: ((8 * %N) + %Base2))` if I add a parameter for iterations.
It would probably make the test easier to follow if the test would use the updated exit condition. It should still reproduce the AddRec issue I think.


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

https://reviews.llvm.org/D133020



More information about the llvm-commits mailing list