[Mlir-commits] [mlir] [MLIR][OpenMP] Add canonical loop LLVM-IR lowering (PR #147069)

[Sergio Afonso]

================
@@ -108,6 +110,41 @@ class ModuleTranslation {
     return blockMapping.lookup(block);
   }
 
+  /// Find the LLVM-IR loop that represents an MLIR loop.
+  llvm::CanonicalLoopInfo *lookupOMPLoop(omp::NewCliOp mlir) const {
----------------
skatrak wrote:

One idea that may work for this would be to introduce yet another operation to the dialect to serve as a context where loop transformations are performed. Something like this:
```mlir
omp.wsloop {
  omp.loop_context {
    %outer_cli = omp.new_cli
    %inner_cli = omp.new_cli
    omp.canonical_loop(%outer_cli) %outer_iv : i32 in range(%outer_tc) {
      omp.canonical_loop(%inner_cli) %inner_iv : i32 in range(%inner_tc) {
        %val = llvm.mlir.constant(42.0 : f32) : f32
        llvm.store %val, %ptr : f32, !llvm.ptr
        omp.terminator
      }
      omp.terminator
    }
    omp.unroll_heuristic(%outer_cli)
    omp.unroll_heuristic(%inner_cli)
    omp.terminator
  }
}
```
Here, the `omp.loop_context` op would take the place of the current `omp.loop_nest`, so it integrates seamlessly with all loop wrappers, and it would have a single block region containing only `omp.new_cli`, `omp.canonical_loop` and loop transformation operations. That would give us a place to create a stack frame holding all information needed to handle loop transformations, and perhaps even let us remove the `omp.new_cli` and instead make CLIs entry block arguments:
```
omp.wsloop {
  omp.loop_context(%outer_cli, %inner_cli) {
    omp.canonical_loop(%outer_cli) %outer_iv : i32 in range(%outer_tc) {
      ...
    }
    ...
  }
}
```

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