[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