[Openmp-commits] [clang] [flang] [llvm] [openmp] [Clang][OpenMP][LoopTransformations] Add support for "#pragma omp fuse" loop transformation directive and "looprange" clause (PR #139293)

[Michael Kruse via Openmp-commits]

Meinersbur wrote:

> I understand this is predicated to the availability of the transformation in `Sema`, but this may not happen if we defer the transformation to `OpenMPIRBuilder` in `CodeGen`. For these cases I presume we cannot emit reliable diagnostics for the validity of the canonical loop nest. Is my understanding correct?

Yes, in that case, either error diagnostic would be deferred to CodeGen (not ideal, but some diagnostics CodeGen are only ermitted in CodeGen), or Semantics would do additional analysis. The `-fopenmp-enable-irbuilder` indented to do that. It introduced a new AST node `OMPCanonicalLoop` that would make such semantic analysis significantly easier. 



> Then I'm confused by this wording here in OpenMP 6.0, Section 11.9 Page 382, in particular the last statement seems to suggest that "presence of the partial clause == the resulting transform is a canonical loop nest". Is this a bug in the spec or I'm interpreting it incorrectly?

This should mean that the partially unrolled loop is a canonical loop nest (of depth one), but this does not refer to what is in the loop body.

I think we have wording in the latest spec that combining a `partial(1)` unrolled loop together with a loop in the body cannot be used as a doacross-loop, but I am not sure about using it as a depth-2 canonical loop in other contexts. In any case, `partial(1)` is a such a unusual corner case that I would not bother about it.

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