[clang] [llvm] [OpenMP] Diagnostic check for imperfect loop collapse (PR #96087)

[Julian Brown via llvm-commits]

jtb20 wrote:

> > I don't think synthesizing a critical region inside the collapsed loop will be a win overall, and also I don't quite see how it helps in this case. A correct version would be doing something like serialising the loop, I think, which I suppose sort of bypasses the problem, but doesn't really solve it. (When would we do such a transformation? How much analysis do we need to avoid killing performance in non-contrived cases?)
> 
> It should be done in the frontend. And here we should care about correctness, not performance. Sure, this can be optimized for better performance later in OpenMPOpt pass, but from the frontend we should get it working correctly.

Apologies -- I meant "when would we do such a transformation" as "under what precise conditions would we do it" rather than "at what point in the compilation pipeline".

I think you're suggesting that we should only perform a genuine loop collapse if we can prove that it is safe (else falling back to some other code transformation*). IIUC that sort of thing isn't normally done with OpenMP -- the compiler does what the user tells it to. Any parallel loop with inter-iteration dependencies will probably compile to wrong code. It's just that for this particular case it seems especially easy to shoot oneself in the foot.

(*) Indeed, maybe just backing out of collapsing the loop nest altogether might be the quickest/safest option. Doing that conservatively might mean essentially never collapsing imperfectly-nested loops though. Is that what we want?

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