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

[Krzysztof Parzyszek via flang-commits]

kparzysz wrote:

It seems like there is a deeper problem here.

Correct me if I'm wrong, it's been a while since I looked at what we do past lowering.  Here's how I see this.

We compile the lowered code that contains both the host and the device code. Then we outline the target regions, and end up with a module that will be further compiled for host, and a module targeted for the device.
Whatever code transformation happens in one of these modules after that split must not invalidate the other.  After the separation the two compilations will be independent from one another.  If we delete a host caller of a target function, it should still be ok for the other module to have the code for the callee, etc.  The situation may be suboptimal, but it has to be correct.

If we make a change to the host code, that requires updates in the target code, this has to happen while we still have both (i.e. before the two modules are permanently separated).  Also, whoever makes the change must do the update to ensure that the result is correct.  If we delete the omp.target region on host, either it should be ok to still proceed with the compilation of the outlined target function, or the device module must be updated accordingly at the same time, or we shouldn't delete omp.target regions after outlining at all (if we can't do any of the other things).

We should not have a situation where passes on these two modules produce outputs that are not consistent with each other.  This new pass seems to try to patch these inconsistencies up, but we shouldn't have them show up in the first place.

 
How do we end up in this situation?

What if the dead code elimination pass (that removes the omp.target) ran before outlining?

Also, seems like there is a legitimate way that some device function may end up without the kernel attribute.  Maybe that should trigger checks whether we need to generate code for it instead of just asserting?


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