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 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
