[PATCH] D15412: [SCEV][LAA] Add no overflow SCEV predicates and use use them to improve strided pointer detection

Adam Nemet via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 2 21:51:37 PST 2016


anemet added inline comments.

================
Comment at: lib/Analysis/LoopAccessAnalysis.cpp:812
@@ -811,3 +811,3 @@
         isa<ConstantInt>(OBO->getOperand(1))) {
-      auto *OpScev = SE->getSCEV(OBO->getOperand(0));
 
----------------
Do you want to try to coerce the expression into affine/non-wrapping here too?  This may be a more common case for C/C++ where we are always inbounds for GEP.

Just asking, it does not have to and probably shouldn't be part of this patch.

================
Comment at: lib/Analysis/LoopAccessAnalysis.cpp:913-916
@@ +912,6 @@
+      Stride != 1 && Stride != -1) {
+    if (Assume) {
+      // We can avoid this case by adding a run-time check.
+      PSE.setNoOverflow(Ptr, SCEVWrapPredicate::IncrementNUSW);
+    } else
+      return 0;
----------------
No {}

Also, any particular reason you have a dbg message above but not here?

================
Comment at: test/Analysis/LoopAccessAnalysis/wrapping-pointer-versioning.ll:7
@@ +6,3 @@
+; For this loop:
+;   unsigned index = n;
+;   for (int i = 0; i < n; i++) {
----------------
Isnt't this initialized to 0 in the IR below?


================
Comment at: test/Analysis/LoopAccessAnalysis/wrapping-pointer-versioning.ll:26-27
@@ +25,4 @@
+; LAA: SCEV assumptions:
+; LAA-NEXT: {0,+,2}<%for.body> Added Flags: <nusw>
+; LAA-NEXT: {%a,+,4}<%for.body> Added Flags: <nusw>
+
----------------
We should include the SCEV for %mul_ext here in a comment between the two.  Probably both with and without the added flag on %mul.  This is more critical later when more things are going on.  This way we'd have the whole reasoning in front of us. 

================
Comment at: test/Analysis/LoopAccessAnalysis/wrapping-pointer-versioning.ll:75-78
@@ +74,6 @@
+;
+; the SCEV expression for A[2 * index] is not an AddRecExpr
+; (and implictly not affine). However, we are able to make assumptions
+; that will turn the expression into an affine one and continue the
+; analysis.
+;
----------------
Don't you mean 2 * index as the expression for this part?  The GEP is covered later.


http://reviews.llvm.org/D15412





More information about the llvm-commits mailing list