[Mlir-commits] [mlir] [OpenMP][MLIR] Add omp.distribute op to the OMP dialect (PR #67720)

Jan Leyonberg llvmlistbot at llvm.org
Mon Oct 2 07:41:25 PDT 2023


jsjodin wrote:

I am thinking one way to resolve this would be to have a single load/store model of CLIs. Instead of omp.canonical_loop defining a CLI as a value, it will set the cli value as an optional operand. That would also allow the loop structure to be defined via ops. Something like this:
```
%cli1 = omp.cli()
%cli2 = omp.cli()
omp.canonical_loop  (%cli1, ...) {
   omp.canonical_loop(%cli2, ...) {
     ...
   }
 }
%cli3 = omp.cli_nest(%cli1, %cli2) // Encode the relationship
%cli4 = omp.unroll(%cli3#0)
```
An added benefit would also be that deleting all the meta-ops would still result in correct code. The invariants should also be pretty few. A CLI value can only be referred to once by a transform-type op (load), and once by a omp.canonical_loop (store) if it is a leaf. A transform op will always produce a new CLI that can be used by a subsequent op. This will encode the ordering of transformations as data dependencies instead of control dependencies, which don't really exist anyway since this is a static view of the program, this also means there shouldn't be any restrictions on the ordering of ops other than def before use. Note that the omp.cli_nest is redundant, since it could be inferred from the structure of the code, however if the code is manipulated outside of the meta-ops it can be used to verify that the code is in the expected form, which was a feature in the original omp.canonical_loop proposal.



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


More information about the Mlir-commits mailing list