[llvm] [LoopInterchange] Add metadata to control loop-interchange (PR #127474)

[Michael Kruse via llvm-commits]

================
@@ -572,6 +578,70 @@ struct LoopInterchange {
 
 } // end anonymous namespace
 
+bool LoopInterchangeList::hasSupportedLoopDepth(
+    OptimizationRemarkEmitter &ORE) {
+  unsigned LoopNestDepth = ListEnd - ListBegin;
+  if (LoopNestDepth < MinLoopNestDepth || LoopNestDepth > MaxLoopNestDepth) {
+    LLVM_DEBUG(dbgs() << "Unsupported depth of loop nest " << LoopNestDepth
+                      << ", the supported range is [" << MinLoopNestDepth
+                      << ", " << MaxLoopNestDepth << "].\n");
+    Loop *OuterLoop = LoopList[ListBegin];
+    ORE.emit([&]() {
+      return OptimizationRemarkMissed(DEBUG_TYPE, "UnsupportedLoopNestDepth",
+                                      OuterLoop->getStartLoc(),
+                                      OuterLoop->getHeader())
+             << "Unsupported depth of loop nest, the supported range is ["
+             << std::to_string(MinLoopNestDepth) << ", "
+             << std::to_string(MaxLoopNestDepth) << "].\n";
+    });
+    return false;
+  }
+  return true;
+}
+
+// Check the metadata for interchange. The outermost one is taken into account
+// and nested ones are ignored. The metadata affects the entire loop nest such
+// that the outermost loop is the loop for which the metadata is specified. For
+// example, in the following example, the loop-interchange will be performed
+// only to the outermost two loops, and the second pragma is ignored.
+//
+// for (...)
+//   for (...)
+//     #pragma clang loop interchange(disable)
+//     for (...)
+//       #pragma clang loop interchange(enable)
+//       for (...)
+//         for (...)
+//           Stmt
+//
----------------
Meinersbur wrote:

> What I'm curious is that, is this desirable behavior for the user? IMO this behavior is a bit confusing for the user. The best solution here would be to apply unroll_and_jam before interchange, but as you said, it's impossible due to the order depends on the default pipeline.

For the existing `#pragma clang loop`, the order is encoded in the order of the passes in the default pass pipeline, so to not cause any changed begavior. This means that e.g.
```c
#pragma clang loop unroll_count(4)
#pragma clang loop vectorize(enable)
```
is the same behaviour as 
```c
#pragma clang loop vectorize(enable)
#pragma clang loop unroll_count(4)
```
or even
```c
#pragma clang loop unroll_count(4) vectorize(enable)
```
This is not something I could change. I would have tried to fix that at one point, but atm I think the frontend would just warn/error out if something looks like it is applied in a specific order, but currently cannot because of pipeline order.


> You meant that, in the code below, the i-loop and j-loop are exchanged first, then the k-loop and l-loop are exchanged. Is my understanding correct?

Yes.

However, if the loops to be interchange were overlapping, the metadata has additional information about the order that you could not represent with pragmas like this.  E.g.

```c
#pragma clang loop interchange(enable)
for (int i = 0; i < N; i++) {
  #pragma clang loop interchange(enable)
  for (int j = 0; j < N; j++) {
    for (int k = 0; k < N; k++) {
```

Do we apply "j <=> k" first, then "k <=> i"? Or does it apply "i <=> j", then "j <=> k"? 

That problem is not solved when using pragmas that specified the entire permutations, they can still overlap:
```c
#pragma clang loop interchange_permutation(j,i,k)
for (int i = 0; i < N; i++) {
  #pragma clang loop interchange_permutation(k,j)
  for (int j = 0; j < N; j++) {
    for (int k = 0; k < N; k++) {
```

Although you could just error-out/warn if the user writes such thing. But to repeat: the metadata representation is independent of how you design the `#pragma` syntax. It just should be unambiguous. Unlike pragmas, you can use groups to select a set of loops that belong to a loop nest. E.g. see `llvm.loop.parallel_accesses` and `llvm.access.group`.

> At first I tried implementing it in this way. But now I feel it would be more useful to affect the entire loop nest rather than against a loop pairwise, since LoopInterchange handles a loop nest. 

That would be fine by me, both representations should be equally powefull. 
The idea was instead of having one mighty metadata, to have smaller, composable metadata. Smaller units is what usually an IR is all about,


> Or, if we want to disable the interchange for some reason and specify it as below, it would be better to stop applying the interchange not only to the i-loop and j-loop, but to the entire loop nest (i.e., including the k-loop and l-loop). WDYT?

I think `#pragma clang loop` only applies on one loop. So in the example, only `i` is not allowed to participate in any loop interchange (either as outer or inner loops). Anything else would be unpredictable. What if `j` was not cosidered a counted loop by LoopInterchange? Then `k` and `l` would sill be their own loop nest and not see the `interchange.disable` metadata.


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