ivanradanov wrote: @skatrak I considered that as well, however, I did not like it because the semantics of the block that the operation is contained in is different. wsloop expects its parent block to be a parallel block which all threads will execute and all of those threads will share the work of the nested loop nest. Whereas the workshare.loop_nest op is semantically executed by a single-thread (because the workshare directive acts like it preserves the semantics of single-threaded fortran execution.).
I don't think it is currently a problem, however, if in the future someone adds some optimization or transformation that assumes that it is nested in a parallel it may break wsloops which happen to be nested in a workshare instead. (As you said it is possible to check whether it is supposed to be a workshare or parallel wsloop but an op changing its semantics or transformations dpeending on what it's nested in feels more error prone). So that is why I opted for this approach. 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
