[flang-commits] [flang] [flang][openmp] Fix incorrect reduction for array section in OpenMP DO SIMD (PR #192394)
Sergio Afonso via flang-commits
flang-commits at lists.llvm.org
Thu Apr 16 08:25:11 PDT 2026
================
@@ -3643,6 +3601,22 @@ static mlir::omp::WsloopOp genCompositeDoSimd(
converter, loc, wsloopClauseOps, wsloopArgs);
wsloopOp.setComposite(/*val=*/true);
+ // For composite DO SIMD, the simd reduction vars must reference the
+ // wsloop's reduction block args (thread-private copies) rather than the
+ // original variables. This ensures that
+ // 1) per-SIMD-lane reduction results are combined into the wsloop's
+ // thread-local copies
+ // 2) wsloop thread-local copies are combined across
+ // threads by the wsloop reduction.
+ auto wsloopBlockArgIface =
+ llvm::cast<mlir::omp::BlockArgOpenMPOpInterface>(*wsloopOp);
+ for (unsigned i = 0; i < simdClauseOps.reductionVars.size() &&
+ i < wsloopBlockArgIface.numReductionBlockArgs();
+ ++i) {
+ simdClauseOps.reductionVars[i] =
+ wsloopBlockArgIface.getReductionBlockArgs()[i];
+ }
----------------
skatrak wrote:
Just a passing comment: This seems in concept related to the fixups that we do in `genLoopVars()`, called by `genLoopNestOp()`, to update inner loop wrapper's arguments when outer ones have mapped them to block arguments (as it's caused by reductions and privatization).
Can you check whether the bug is an edge case not handled there or confirm that it is a different problem that we can't deal with at that point? In any case, I agree with @tblah that this seems to not be specific to array sections or `do simd`.
https://github.com/llvm/llvm-project/pull/192394
More information about the flang-commits
mailing list