eZWALT wrote: > > @alexey-bataev After conducting an examination of the directive handling > > logic, I can confidently state that the number of generated loops > > (`NumGeneratedLoops`) does not affect the semantic checks for the majority > > of transformations. This is because values are usually hardcoded in the > > `ActOnXXX` semantic handlers. For example: > > > > * In the case of the `'reverse'` directive, the number of loops > > (`NumLoops`) is hardcoded to `1`, meaning it remains unaffected by any > > external loop count logic. > > * For the `'interchange'` directive, the number of loops is also explicitly > > set using the following logic: > > > > ``` > > size_t NumLoops = PermutationClause ? PermutationClause->getNumLoops() : 2; > > ``` > > > > > > > > > > > > > > > > > > > > > > > > These values are passed into the `checkTransformableLoopNest` function and > > are not accessed elsewhere in the codebase, except: > > > > * In `doForAllLoops`, where only the **presence** of loops is checked > > (i.e., `NumLoops == 0` or `> 0`), not the actual count, therefore this > > change won't break this conditional flow. > > * In the newly introduced analysis functions (as part of the `'fuse'` > > transformation: [[Clang][OpenMP][LoopTransformations] Add support for > > "#pragma omp fuse" loop transformation directive and "looprange" clause > > #139293](https://github.com/llvm/llvm-project/pull/139293)), specifically > > within `checkTransformableLoopSequence`, where both `NumGeneratedLoops` and > > `NumGeneratedLoopNests` are read and actively utilized. > > Can you remove these hardcoded values and use the stored value instead? > Otherwise, it is meaningless and should be removed
But this rigidity stems from the `checkTransformableLoopNest`, which needs the number of loops to be specified beforehand. Changing this wouldn't make much sense. The `NumGeneratedLoops` information is only available after the creation of the `OMPLoopTransformation` AST nodes, but the number of loops must be known before that. Note that inferring this knowledge is trivial in the old scheme of loop transformations, since almost all have one top-level loop, or the loop count is specified by a clause , for example, `PermutationClause`. `OMPFuseDirective` is the only one where the number of loops (both top-level and nested) is dynamic, depending on the user code. Therefore, it is mandatory to do an analysis to gather the shape of the loop sequence. Probably I haven’t explained myself well enough, but I want to stress the difference: - `NumLoops` refers to the loops *expected* or known beforehand — which, in most directives, can be hardcoded. - `NumGeneratedLoops` is the total number of loops *after* transformation, stored as semantic information in the AST. - `NumGeneratedLoopNests` is the number of top-level loop nests, which is important for loop sequence transformations like `fuse` or `split`. **Summing up**: preserving this semantic information is important, and there’s no reason to change it right now. Feel free to digress, but I’m confident this is the right approach. https://github.com/llvm/llvm-project/pull/140532 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
