[llvm] [LoopInterchange] Consider forward/backward dependency in vectorize heuristic (PR #133672)

[Michael Kruse via llvm-commits]

================
@@ -1334,21 +1405,34 @@ LoopInterchangeProfitability::isProfitablePerInstrOrderCost() {
 static bool canVectorize(const CharMatrix &DepMatrix, unsigned LoopId) {
   for (const auto &Dep : DepMatrix) {
     char Dir = Dep[LoopId];
-    if (Dir != 'I' && Dir != '=')
-      return false;
+    char DepType = Dep.back();
+    assert((DepType == '<' || DepType == '*') &&
+           "Unexpected element in dependency vector");
+
+    // There are no loop-carried dependencies.
+    if (Dir == '=' || Dir == 'I')
+      continue;
+
+    // DepType being '<' means that this direction vector represents a forward
+    // dependency. In principle, a loop with '<' direction can be vectorized in
+    // this case.
+    if (Dir == '<' && DepType == '<')
+      continue;
+
+    // We cannot prove that the loop is vectorizable.
+    return false;
   }
   return true;
 }
 
 std::optional<bool> LoopInterchangeProfitability::isProfitableForVectorization(
     unsigned InnerLoopId, unsigned OuterLoopId, CharMatrix &DepMatrix) {
-  // If the outer loop is not loop independent it is not profitable to move
-  // this to inner position, since doing so would not enable inner loop
-  // parallelism.
+  // If the outer loop cannot be vectorized, it is not profitable to move this
+  // to inner position.
   if (!canVectorize(DepMatrix, OuterLoopId))
     return false;
 
-  // If inner loop has dependence and outer loop is loop independent then it is
+  // If inner loop cannot be vectorized and outer loop can be then it is
----------------
Meinersbur wrote:

The feature of the red-green tree is that is allows for cheap/shallow copies of the IR that can be speculatively modified without committing to the change. So in this case, you would apply interchange to it, then try to vectorize. If vectorization turns out to be profitable, great, you make it the primary representation (and transform it back into LLVM-IR). If it is not profitrable, throw it away.

VPlan is not designed this way, but relies that you have just one representation with unspecified vector length (and assuming vectorizaiton along a specific loop, currently only the innermost). You only do profitability analysis with specific vector lengths, and keep the most profitable (or discard the entire thing if none turns out to be profitable). But creating the VPlan itself is expensive and already assumes that the specific loop is vectorizable. To speculativelty vectorize, you first have to make a copy of the entire IR, apply interchange on it, then VPlan; and compare it to the VPlan from the original code. Quite expensive.

There is [SandboxIR](https://llvm.org/docs/SandboxIR.html), but it is instruction-focused, not loop-focused. You also cannot have multiple variants of the IR in memory at the same time.


>  So I came to the conclusion that things aren't quite that simple after all.

Because of this I would not bother trying apply another pass' analysis on speculative changes. #146383 does not, but it gets complex quickly.

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