[flang-commits] [flang] [llvm] [flang][OpenMP] Sink intervening code unguarded into collapsed loop body (PR #225159)

[Caroline Newcombe via flang-commits]

cenewcombe wrote:

> Cases 1 and 2 are about frequency, where the OpenMP wording likely allows some leniency. Cases 3 and 4 look incorrect, even though they match Clang's behavior.

Thanks @sshrestha-aa. Since the spec specifically says the execution count is unspecified (within a limited range), I don't think the considerations for case 3 are any different than 1&2. Although the result may not be what the user expects, I don't think this patch violates the spec.

Case 4 is a little different, but we are conforming with the restrictions on the loop iteration variable that I can find in the spec, from Section 6.4.3:
> At the beginning of each collapsed iteration in a loop-collapsing construct, the loop-iteration variable or the variable declared by range-decl of each collapsed loop has the value that it would have if the collapsed loops were not associated with any directive.

For `!$omp parallel do collapse(2)` the iteration variables are predetermined private, so there's no writeback pinning a value after the construct either. I can't find anything specifying the value during a collapsed iteration, which is where `ksave = j` executes. What we emit there is the value 6.4.3 requires at the start of that collapsed iteration, left unmodified; producing `m+1` would mean synthesizing and writing a value into `j` that the spec doesn't mention. I am hesitant to go down that route.

That said, I'm not a spec expert — happy to hear other readings.

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