[PATCH] D28044: [LV/LoopAccess] Check statically if an unknown dependence distance can be proven larger than the loop-count

[Michael Kuperstein via Phabricator via llvm-commits]

mkuper added a comment.

Hi Dorit, sorry for the delay - I don't know SCEV and LAA well enough yet, and I spent some time happily ignoring this, without noticing nobody else reviewed it either. :)



================
Comment at: llvm/lib/Analysis/LoopAccessAnalysis.cpp:1303
   if (!C) {
+    if (TypeByteSize == DL.getTypeAllocSize(BTy)) {
+      DEBUG(dbgs() << "LAA: non-constant distance: " << *Dist << "\n");
----------------
Can this be an early exit?


================
Comment at: llvm/lib/Analysis/LoopAccessAnalysis.cpp:1310
+      // (this is equivalent to what the SIV data-dependence test would do).
+      const SCEV *BackedgeTakenCount = PSE.getBackedgeTakenCount();
+      const uint64_t ByteStride = Stride * TypeByteSize;
----------------
Can you use getMaxBackedgeTakenCount()?
If the count is precisely known, then they should be equivalent. If it's not, then since by definition MaxBackedgeTakenCount >= BackedgeTakenCount, the equation above also holds.

(I'm not sure if ever vectorize when we don't have a precise getBackedgeTakenCount(), but even if we don't, no need for extra constraints here)


================
Comment at: llvm/lib/Analysis/LoopAccessAnalysis.cpp:1325
+
+      // Is (Dist > takenCount * stepInBytes) ?
+      // (If so, then we have proven (**) because |dist| >= dist)
----------------
(Sorry for possibly rehashing the discussion you had with Silviu)
The code looks fine, but I'm not entirely sure I understand why this is the best way to approach this. I've read through PR31098, and it probably contains the information I'm looking for, but it's spread over separate messages and it's a bit hard for me to follow.

1) Why can't you offload this into SCEV? Is the problem representing |dist| as a SCEV, or that SCEV can't prove |dist| - product is positive?
2) While this may be a good idea independently, wouldn't cases like PR31098, in general be better served by improving alias analysis, and then being able to prove that 8D >= 0?


https://reviews.llvm.org/D28044