================
@@ -189,6 +190,26 @@ class LinearClauseProcessor {
}
}
+ // Find linear iteration variable and save it for later updates
+ void initLinearIV(omp::SimdOp simdOp) {
+ auto loopOp = cast<omp::LoopNestOp>(simdOp.getWrappedLoop());
+ // NOTE iteration variables can only be linear in non-nested loops.
+ if (loopOp.getIVs().size() != 1)
+ return;
+ // The linear IV is the loop IV's store address.
+ BlockArgument arg = loopOp.getIVs().front();
+ for (const Operation *user : arg.getUsers()) {
+ if (auto storeOp = dyn_cast<LLVM::StoreOp>(user)) {
+ for (Value linearVar : simdOp.getLinearVars()) {
----------------
tblah wrote:
This fails if the linear loop iteration variable is not stored directly to an
address listed in simdOp.getLinearVars(). This can happen in cases like
`linear(%i ...) private(... %i -> %arg0 ...)` because the loopIV is stored to
`%arg0`.
If I understand correctly, this case is avoided by the earlier flang patches,
but I think we do at least need a translation failure here in MLIR for this
case so that any future frontends using this understand the limitation.
Ideally, this should be checked in the OpenMP dialect verifier.
Note that this form is still used in
`mlir/test/Target/LLVMIR/openmp-simd-ordered.mlir`.
https://github.com/llvm/llvm-project/pull/183800
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
