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

[Sergio Afonso via flang-commits]

skatrak wrote:

@abidh you are correct about how target offloading is currently handled: there are multiple frontend invocations (one for the host and one for each offloading target), each producing an independent MLIR module, so there's never a common MLIR module (though we do expect them to initially be very similar). This behavior is shared with Clang, and one of the reasons for this approach, IIRC, is that there could be e.g. preprocessor logic causing code variations between targets.

We do function filtering relatively early (still within Flang), which seems to be the reason why we end up with different lists of target regions. One of the advantages of that is that we avoid processing potentially large amounts of host-only code in MLIR only to get rid of it at the end, but we'd probably address this issue if we updated that pass to run right before translation to LLVM IR. That would have the advantage of not making host and device MLIR modules diverge much until the very end, and other compiler frontends targeting OpenMP offloading could benefit from function filtering too.

One other alternative approach I would suggest considering would be to update the `FunctionFiltering` pass instead of introducing a new pass. Basically, the idea would be to detect unreachable target regions there and to add them to a local "blacklist". Then, the regular filtering logic would run normally, but removing unreachable target regions. That might not need as much new logic to be introduced, but I've got a good chunk of changes planned for that pass and it probably makes more sense to delay the consolidation until both features are working and tested.

In any case, I don't see a good reason to add an attribute to target regions to mark them as "deleted". I'd prefer to just delete them when this situation is detected. In terms of moving around function filtering within the compilation flow, for the time being I'm leaning towards keeping things as they are (less potentially breaking changes to be done, and it doesn't appear that diverging optimizations of host and device code could become a regular source of problems). We might want to discuss this later, with regards to reuse among multiple frontends, though.

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