[llvm] [LAA] Be more careful when evaluating AddRecs at symbolic max BTC. (PR #106530)

David Sherwood via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 2 02:27:23 PDT 2024


================
@@ -219,13 +219,29 @@ static std::pair<const SCEV *, const SCEV *> getStartAndEndForAccess(
   const SCEV *ScStart;
   const SCEV *ScEnd;
 
+  auto &DL = Lp->getHeader()->getDataLayout();
+  Type *IdxTy = DL.getIndexType(PtrExpr->getType());
+  const SCEV *EltSizeSCEV = SE->getStoreSizeOfExpr(IdxTy, AccessTy);
   if (SE->isLoopInvariant(PtrExpr, Lp)) {
     ScStart = ScEnd = PtrExpr;
   } else if (auto *AR = dyn_cast<SCEVAddRecExpr>(PtrExpr)) {
-    const SCEV *Ex = PSE.getSymbolicMaxBackedgeTakenCount();
-
     ScStart = AR->getStart();
-    ScEnd = AR->evaluateAtIteration(Ex, *SE);
+    const SCEV *BTC = PSE.getBackedgeTakenCount();
+    if (!isa<SCEVCouldNotCompute>(BTC))
+      ScEnd = AR->evaluateAtIteration(BTC, *SE);
----------------
david-arm wrote:

I guess I probably don't understand LoopAccessAnalysis well enough here, but I tried out this patch and ran SCEV analysis on this loop:

```
loop:
  %iv = phi i32 [ %y, %entry ], [ %iv.next, %loop ]
  %gep1.iv = getelementptr inbounds i32, ptr %S, i32 %iv
  %load = load i32, ptr %gep1.iv, align 4
  %gep2.iv = getelementptr inbounds i32, ptr %P, i32 %iv
  store i32 %load, ptr %gep2.iv, align 4
  %iv.next = add nsw i32 %iv, 1
  %c.2 = icmp slt i32 %iv.next, 2147483647
  br i1 %c.2, label %loop, label %exit
```

and with the exact BTC the debug output looks like this:

```
    Grouped accesses:
      Group 0xaaaaf5a0b678:
        (Low: ((4 * %y) + %P) High: (-4 + %P))
          Member: {((4 * %y) + %P),+,4}<%loop>
      Group 0xaaaaf5a0b6a8:
        (Low: ((4 * %y) + %S) High: (-4 + %S))
          Member: {((4 * %y) + %S),+,4}<%loop>
```

The High value has still wrapped and looks wrong. Are you saying that some code in LoopAccessAnalysis will bail out before even attempting to use the High value if the backedge taken count is exact, whereas for a symbolic backedge taken count we take a different code path and will still attempt to use the High value?

https://github.com/llvm/llvm-project/pull/106530


More information about the llvm-commits mailing list