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

[David Sherwood via llvm-commits]

================
@@ -188,9 +188,56 @@ RuntimeCheckingPtrGroup::RuntimeCheckingPtrGroup(
   Members.push_back(Index);
 }
 
+/// Return true, if evaluating \p AR at \p MaxBTC cannot wrap, because \p AR at
+/// \p MaxBTC is guaranteed inbounds of the accessed object.
+static bool evaluateAddRecAtMaxBTCWillNotWrap(const SCEVAddRecExpr *AR,
+                                              const SCEV *MaxBTC,
+                                              ScalarEvolution &SE,
+                                              const DataLayout &DL) {
+  auto *PointerBase = SE.getPointerBase(AR->getStart());
+  auto *StartPtr = dyn_cast<SCEVUnknown>(PointerBase);
+  if (!StartPtr)
+    return false;
+  bool CheckForNonNull, CheckForFreed;
+  uint64_t DerefBytes = StartPtr->getValue()->getPointerDereferenceableBytes(
+      DL, CheckForNonNull, CheckForFreed);
+
+  if (CheckForNonNull || CheckForFreed)
+    return false;
+
+  const SCEV *Step = AR->getStepRecurrence(SE);
+  Type *WiderTy = SE.getWiderType(MaxBTC->getType(), Step->getType());
+  Step = SE.getNoopOrSignExtend(Step, WiderTy);
+  MaxBTC = SE.getNoopOrSignExtend(MaxBTC, WiderTy);
----------------
david-arm wrote:

Why is this a sign-extend? Is there something that prevents the max btc in the original IR be unsigned? i.e.

```
   %iv = phi i32 [ 0, %entry ], [ %iv.next, %latch ]
   ...
   possible jump to early exit
   latch:
   %iv.next = add nuw nsw i32 %iv, 1
   %cond = icmp ult i32 %iv, %n
```

Or do we introduce SCEV checks before the loop to ensure that `%n` never has the sign-bit set?

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