[PATCH] D86071: [MLIR][OpenMP] Add omp.do operation

[Uday Bondhugula via Phabricator via llvm-commits]

bondhugula added a comment.

In D86071#2265876 <https://reviews.llvm.org/D86071#2265876>, @ftynse wrote:

>> I guess for the general workshare loop design issues we can have an RFC in discourse. But this patch can go ahead.
>
> I haven't seen answers to the questions about lowering to LLVM IR + OpenMP runtime, and it sounds suboptimal to push the patch before discussing and agreeing on the actual design.
>
> In particular, it is not clear to me how this construct will connect to loops and what the lowering flow is. Does it expect an `scf.for`/`scf.parallel` as the only nested op? Is there a plan for a separate `omp.for`? How long do loops persist when we go to LLVM, given that OpenMPIRBuilder does not handle loop constructs and we really want to avoid converting loops to CFG during MLIR->LLVM IR translation.

+1 on having clarity on the lowering part to LLVM dialect.  I think the op itself doesn't place any restrictions on what's inside. There could be `scf.for` ops nested inside or surrounding an `omp.do` given that they both use the same type subsystem (standard types). One would expect an `scf.parallel` to be converted to an omp.do? The remaining scf.for's would be lowered to LLVM dialect the usual way. It looks like we need some sort of a pre-pass on the LLVM dialect to lower/handle the `omp.do` and some of the implementation therein would have to duplicate/reuse the logic of the `scf.for` lowering. @DavidTruby @kiranchandramohan - do you have an example sketch of how the LLVM dialect would like for a simple / minimal omp.do loop right before it's translated out to LLVM IR proper? Would it require duplicating LLVM's OpenMPIRBuilder functionality here on the LLVM dialect?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86071/new/

https://reviews.llvm.org/D86071