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

[Ivan R. Ivanov via llvm-branch-commits]

ivanradanov wrote:


> Can you share a case where this would happen? I agree that we wouldn't want to produce some IR that doesn't keep consistent semantics for a given operation across the pipeline. In that case, adding another operation might indeed be the right solution.

I was under the impression that direct PFT to FIR lowering is deprecated, so things like array notation (e.g. z = x + y where x,y,z are arrays) always go through hlfir.elemental and then to fir loops. Not sure if the PFT->FIR lowering for that exists, but if PFT->FIR is deprecated then we should probably use the HLFIR lowering for this.

> My main concern is from the dialect design perspective. It would be confusing to have two separate "worksharing loop" operations with one being used on its own and the other one in conjunction with the `omp.workshare` operation, but both basically representing the same thing (splitting loop iterations across threads in the team). That's why I'm trying to explore other options that may result in a better representation before committing to it.

I think the operations describe very different things. The similarity in naming is an unfortunate consequence of the `workshare` construct having the same name as a `workshare loop` (I am open to more descriptive name suggestions). How I read it is: `omp.wsloop` is "each thread from from the team that encounter it, executes its share of the loop nest" whereas `omp.workdistribute.loop_wrapper` is "this loop nest is marked for dividing into units of work by the encompassing `omp.workshare`" (as per the standard). Semantically, it is just a loop nest that is executed by a single thread and only when the workshare lowering transforms it into an `omp.wsloop` does it turn into a worksharing loop.

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