[llvm] [LAA] Refine stride checks for SCEVs during dependence analysis. (PR #99577)

[Florian Hahn via llvm-commits]

================
@@ -1987,11 +1979,47 @@ MemoryDepChecker::getDependenceDistanceStrideAndSize(
     }
   }
 
-  // Need accesses with constant strides and the same direction. We don't want
-  // to vectorize "A[B[i]] += ..." and similar code or pointer arithmetic that
-  // could wrap in the address space.
-  if (!StrideAPtr || !StrideBPtr || (StrideAPtr > 0 && StrideBPtr < 0) ||
-      (StrideAPtr < 0 && StrideBPtr > 0)) {
+  // Need accesses with constant strides and the same direction for further
+  // dependence analysis. We don't want to vectorize "A[B[i]] += ..." and
+  // similar code or pointer arithmetic that could wrap in the address space.
+  //
+  // If Src or Sink are non-wrapping AddRecs, StrideAPtr and StrideBPtr contain
+  // a SCEV representing the stride of the SCEV. It may not be a known constant
+  // value though.
+
+  // If either Src or Sink are not strided (i.e. not a non-wrapping AddRec), we
+  // cannot analyze the dependence further.
+  if (!StrideAPtr || !StrideBPtr) {
+    bool SrcInvariant = SE.isLoopInvariant(Src, InnermostLoop);
+    bool SinkInvariant = SE.isLoopInvariant(Sink, InnermostLoop);
+    // If either Src or Sink are not loop invariant and not strided, the
+    // expression in the current iteration may overlap with any earlier or later
+    // iteration. This is not safe and we also cannot generate runtime checks to
+    // ensure safety. This includes expressions where an index is loaded in each
+    // iteration or wrapping AddRecs.
+    if ((!SrcInvariant && !StrideAPtr) || (!SinkInvariant && !StrideBPtr))
+      return MemoryDepChecker::Dependence::IndirectUnsafe;
----------------
fhahn wrote:

I originally was worried about other users of getPtrStride which may not handled be all callers properly. But it looks like all all other callers use `.value_or(0)` so we should be fine to update it as suggested.

Did this in the latest version, should be much simpler now, thanks!

> (NB: Pretty weird to call the more constrained case "Unknown")

Agreed, naming could be improved separately

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