[Mlir-commits] [mlir] [mlir][OpenMP] inscan reduction modifier and scan op mlir support (PR #114737)

[Sergio Afonso]

================
@@ -1560,6 +1560,26 @@ def CancellationPointOp : OpenMP_Op<"cancellation_point", clauses = [
   let hasVerifier = 1;
 }
 
+def ScanOp : OpenMP_Op<"scan", [
----------------
skatrak wrote:

My understanding is that clang would be able to base the implementation of `scan` on the position of the directive within the loop body (just like how it's defined at the source level by the spec) because the AST is not modified by moving statements around possibly crossing the `scan` split point. Which would also be the reason why you are able to parse it that way in Flang.

However, MLIR transformation passes are able to move operations within a region in a way that would potentially break `scan`. We must make sure the MLIR representation we choose prevents this from happening, and at the moment the best I can think of would be the 2-region alternative I illustrated above.

But I see the problem you point to about the naming of these regions. However, if instead of calling them `input` and `scan`, we call them `pre` and `post` then we should be able to lower them to LLVM IR properly based on whether it's an `inclusive` or `exclusive` scan. That would mean something like this:
```mlir
omp.wsloop reduction(inscan @reduction %0 -> %red0 : !llvm.ptr) {
  omp.loop_nest ... {
    omp.scan exclusive(%red0 : !llvm.ptr)
    pre {
      // Everything before '!$omp scan ...'
      ...
      omp.terminator
    } post {
      // Everything after '!$omp scan ...'
      ...
      omp.terminator
    }
    omp.yield
  }
}
```
The questions that I guess would remain for this approach would be whether we can let common sub-expressions, constants etc. be hoisted out of the `pre` and `post` regions, whether we should allow other non-terminator operations after `omp.scan` inside of the loop and whether we need to make values defined in `pre` accessible to `post` by having an `omp.yield` terminator for the former and corresponding entry block arguments for the latter.

CC: @kiranchandramohan, @tblah.

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