[Mlir-commits] [flang] [mlir] [Flang][OpenMP] Don't generate code for unreachable target regions. (PR #178937)

[Abid Qadeer]

abidh wrote:

> It seems like there is a deeper problem here.

Thanks for you comment @kparzysz. I am also new to this area. Here is what I understand about this problem.

When we give the offload flag (--offload-arch) to the driver, the compiler is run twice: once in host mode and once for device.

**Host compilation:**
- Keeps all code including control flow (e.g., `fir.if %false { omp.target }`)
- Later, when `SimplifyConstCondBranchPred` runs (after CFG conversion), it removes unused blocks along with any target regions in them

**Device compilation:**
- `FunctionFilteringPass` (which runs only on device) removes all non-target code and hoists target regions out of their control flow nesting
- After this pass, the `fir.if` and other host-side control flow are gone
- Later passes (including `SimplifyConstCondBranchPred`) have no knowledge that the target region was originally in an unreachable block

So there is an inconsistency between host and device.

**Our approach:**
We run `MarkUnreachableTargetsPass` in the OpenMP FIR pipeline, **before** `FunctionFilteringPass` (which is the point where host and device IR diverge). At this stage:
- Both host and device still have the full control flow structure
- We can detect unreachable target regions
- We mark them with `omp.target_unreachable` attribute
- This attribute survives `FunctionFilteringPass` hoisting and travels with the operation
- Both host and device skip code generation for marked targets during MLIR→LLVM translation

This ensures host-device synchronization preventing the inconsistency before outlining happens.

> whether we need to generate code for it instead of just asserting?

The assertion in OpenMPOpt is relatively harmless and could be changed to a warning or early return. However, the changes in this PR fix the problem at the root cause level and also avoid unnecessarily processing code that will never execute.

https://github.com/llvm/llvm-project/pull/178937