[PATCH] D62939: Strengthen LFTR's ability to replace IVs

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 6 09:38:06 PDT 2019


nikic added inline comments.


================
Comment at: lib/Transforms/Scalar/IndVarSimplify.cpp:2106
 
+/// Return true undefined behavior would provable be executed on all iterations
+/// for which Root produced a poison result, and the loop exit condition for
----------------
nit: Return true //if// ... provably


================
Comment at: lib/Transforms/Scalar/IndVarSimplify.cpp:2109
+/// ExitingBB is evaluated.  Note that this doesn't say anything about whether
+/// LoopExiting BB is actually executed or taken.  This can be used to assess
+/// whether a new use of Root can be added before ExitingBB's terminator without
----------------
nit: s/LoopExisting BB/ExitingBB


================
Comment at: lib/Transforms/Scalar/IndVarSimplify.cpp:2128
+    Instruction *I = Worklist.pop_back_val();
+    if (!Visited.insert(I).second)
+      continue;
----------------
I feel like there's some confusion here between instructions that have a poison operand and instructions that produce poison. As you're inserting into Visited before doing the propagation test, Visited holds instructions that have a poison operand. However, in the `Visited.count(NotPoison)` check below you are assuming that Visited instructions return poison.


================
Comment at: lib/Transforms/Scalar/IndVarSimplify.cpp:2143
+    if (isa<StoreInst>(PoisonI))
+      return true;
+    if (PoisonI == ExitingBB->getTerminator())
----------------
Why is this condition separate? This seems wrong for a) non-dominating store and b) poison being on the value operand, not the pointer operand.


================
Comment at: lib/Transforms/Scalar/IndVarSimplify.cpp:2145
+    if (PoisonI == ExitingBB->getTerminator())
+      return true;
+    // If we know this must trigger UB on a path leading to our exit, we're
----------------
I think this isn't right as documented (branching on poison is not UB and there may be abnormal exits), though it seems okay for the purpose we need this.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62939





More information about the llvm-commits mailing list