koparasy 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? Technically you can, it sounds like a big effort. If we rely on `omp` dialect it will do quite some work for CIR, otherwise I guess we will need to emit CIR for the constructs, and those are plenty. When you say "broadly assuming" does this refer to the placement of alloca's and the goto solver? I am wondering though if we wrap the parallel region body in a terminate scope in CIRGen, whether it would fix this current bug, without any specific logic in EHABLowering. https://github.com/llvm/llvm-project/pull/230509 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
