andykaylor wrote: > > Why do we still have nested regions after running FlattenCFG? I think the > > problem here is that we're not flattening omp.parallel. > > AFAIU the omp dialect, the omp.parallel op itself can't be inlined into the > parent CFG. Tater that region will be called indirectly by the OMP runtime. > It stays a region through MLIR, and OpenMPIRBuilder outlines it into the > `.omp_par` function (handling captured values) during translation to LLVM IR. > The region boundary is therefore a function boundary, so every landing pad > for a call in the region has to live in the region too.
Yeah, I saw the outlining, but it wasn't clear to me where that was happening. This is a potential problem for CIR because the passes that run after Flatten CFG are broadly assuming that there are no nested regions in CIR functions, which leads to problems like the one this PR is attempting to fix. Would it be possible to do the OpenMP outlining before FlattenCFG? https://github.com/llvm/llvm-project/pull/230509 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
