skatrak wrote:
> I am debating introducing a new operation workshare_loop_container which
> exists only to "contain" a omp.loop_nest between lowering an elemental to
> lowering the omp.workshare it is contained in.
>
> so we would have this state:
>
> ```
> omp.workshare {
> omp.workshare_loop_container {
> omp.loop_nest {}
> }
> }
> ```
>
> ```
> omp.workshare {
> omp.wsloop {
> omp.loop_nest {}
> }
> }
> ```
>
> Which may have come from a different lowering/codegen and we are not sure
> what the semantics of that code would be.
>
> This new operation can later be reused for the `workdistribute` lowering as
> well.
I've been thinking about it and I believe we could actually use `omp.wsloop`
rather than creating a new loop wrapper just for this. The reason is that,
according to the spec, "the only OpenMP constructs that may be closely nested
inside a `workshare` construct are the `atomic`, `critical` and `parallel`
constructs" (5.2 spec, page 246). So there's no other way we could end up with
an `omp.wsloop` nested directly inside of `omp.workshare` other than to
represent these elementals.
The only difference is that perhaps we could enforce tighter restrictions to
the `omp.wsloop` MLIR verifier if it's nested inside `omp.workshare` (e.g. it's
not composite, it doesn't have any clause specified, etc).
https://github.com/llvm/llvm-project/pull/101445
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
