[llvm-branch-commits] [flang] [flang] Introduce custom loop nest generation for loops in workshare construct (PR #101445)

[Sergio Afonso via llvm-branch-commits]

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