rofirrim wrote: Hi @Meinersbur, thanks for the detailed answer.
> Just recording the loop nesting of this may result in gls = [ 3 ]. Ovever, > the tile size depends on the outer loop which the OpenMP restrictions on > canonical loop nests do not allow. Right, this breaks my suggested bottom-up analysis. Thanks for this counterexample. > One may track the dependencies through all the clauses and loop bounds, but I > think it is sufficient to let `checkOpenMPLoop` diagnose all those > restrictions once `getTransformedStmt()` is guarenteed to be available. 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? Anyways, no need to complicate matters further for this PR :-) You also say: > In the OpenMP spec the unrolled body is never a valid canonical loop, even > with partial(1), nor a loop sequence, a concept that was added after unroll. > I am not sure what the use case would be for considering the unrolled loop > body to be a canonical loop sequence 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? <img width="841" height="113" alt="image" src="https://github.com/user-attachments/assets/abf250c4-41fc-4c95-9b8b-86ba1833a31e"; /> Thanks! https://github.com/llvm/llvm-project/pull/139293 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
