diff options
author | Michael Kruse <llvm-project@meinersbur.de> | 2021-10-06 11:43:29 -0500 |
---|---|---|
committer | Michael Kruse <llvm-project@meinersbur.de> | 2021-10-06 12:21:04 -0500 |
commit | 2130117f92e51df73ac8c4b7e37f7f89178a89f2 (patch) | |
tree | 6c7abd71a817e367211b6f65257fdc066c4ac843 /llvm/lib/CodeGen/SafeStack.cpp | |
parent | fdf4c035225de52f596899931b1f6100e5e3e928 (diff) | |
download | llvm-2130117f92e51df73ac8c4b7e37f7f89178a89f2.zip llvm-2130117f92e51df73ac8c4b7e37f7f89178a89f2.tar.gz llvm-2130117f92e51df73ac8c4b7e37f7f89178a89f2.tar.bz2 |
[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
Diffstat (limited to 'llvm/lib/CodeGen/SafeStack.cpp')
0 files changed, 0 insertions, 0 deletions