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

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 31 07:43:20 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:
> 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`?


================
Comment at: llvm/test/Analysis/LoopAccessAnalysis/forked-pointers.ll:925
+for.body.us:
+  %indvars.iv.us1 = phi i64 [ %indvars.iv.next.us, %for.body.us ], [ 0, %entry ]
+  %indvars79.us = trunc i64 %indvars.iv.us1 to i32
----------------
The IR value names here seem a bit long which makes things a bit harder to read. It would probably be good to remove the naming prefixes/suffixes added be LLVM transforms (.e.g `indvars`, `i.i.`, `.us`)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133020



More information about the llvm-commits mailing list