[all-commits] [llvm/llvm-project] 213011: [Clang][OpenMP] Allow loop-transformations with te...

[Michael Kruse via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2130117f92e51df73ac8c4b7e37f7f89178a89f2
      https://github.com/llvm/llvm-project/commit/2130117f92e51df73ac8c4b7e37f7f89178a89f2
  Author: Michael Kruse <llvm-project at meinersbur.de>
  Date:   2021-10-06 (Wed, 06 Oct 2021)

  Changed paths:
    M clang/include/clang/AST/StmtOpenMP.h
    M clang/lib/AST/StmtOpenMP.cpp
    M clang/lib/Sema/SemaOpenMP.cpp
    M clang/lib/Serialization/ASTReaderStmt.cpp
    M clang/lib/Serialization/ASTWriterStmt.cpp
    M clang/test/OpenMP/tile_ast_print.cpp
    M clang/test/OpenMP/unroll_ast_print.cpp

  Log Message:
  -----------
  [Clang][OpenMP] Allow loop-transformations with template parameters.

Clang would reject

    #pragma omp for
    #pragma omp tile sizes(P)
    for (int i = 0; i < 128; ++i) {}

where P is a template parameter, but the loop itself is not
template-dependent. Because P context-dependent, the TransformedStmt
cannot be generated and therefore is nullptr (until the template is
instantiated by TreeTransform). The OMPForDirective would still expect
the a loop is the dependent context and trigger an error.

Fix by introducing a NumGeneratedLoops field to OMPLoopTransformation.
This is used to distinguish the case where no TransformedStmt will be
generated at all (e.g. #pragma omp unroll full) and template
instantiation is needed. In the latter case, delay resolving the
iteration space like when the for-loop itself is template-dependent
until the template instatiation.

A more radical solution would always delay the iteration space analysis
until template instantiation, but would also break many test cases.

Reviewed By: ABataev

Differential Revision: https://reviews.llvm.org/D111124