[flang-commits] [flang] [flang][openmp] Fix incorrect reduction for array section in OpenMP DO SIMD (PR #192394)

[Sergio Afonso via flang-commits]

================
@@ -696,6 +699,21 @@ bool ReductionProcessor::processReductionArguments(
   }
 
   for (const semantics::Symbol *symbol : reductionSymbols) {
+    // If a cached reduction variable exists for this symbol, reuse it.
+    // This ensures that composite constructs (e.g. DO SIMD) where both
+    // the outer wrapper (wsloop) and inner wrapper (simd) process the same
+    // reduction clause share the same SSA value, enabling genLoopVars()'s
+    // IRMapping to correctly remap inner wrapper operands to outer wrapper
+    // block arguments.
+    if (reductionVarCache) {
+      auto it = reductionVarCache->find(symbol);
+      if (it != reductionVarCache->end()) {
+        reductionVars.push_back(it->second);
+        reduceVarByRef.push_back(doReductionByRef(it->second));
+        continue;
----------------
skatrak wrote:

Adding these here, together with the pre-existing `push_back()` calls below on the same vectors, cause them to fall out of sync with the `reductionSymbols` (i.e. they no longer have the same lengths and the same index doesn't refer to the same reduction variable).

They eventually make it to an `EntryBlockArgs` structure as the `.syms` and `.vars` fields, which are then used in the calls to `genEntryBlock` (called by `genWrapperOp`) and `bindEntryBlockArgs` (called by `genLoopVars` via `genLoopNestOp`). The former creates the entry block argument list based on `.vars` and the latter uses `.syms` and `.vars` to map MLIR values to these symbols.

Am I missing something? How does this not cause a problem?

https://github.com/llvm/llvm-project/pull/192394