[Mlir-commits] [mlir] [mlir][OpenMP] Fix update of linear iteration variables (PR #183800)

[Tom Eccles]

================
@@ -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()) {
+          if (linearVar == storeOp.getAddr()) {
+            linearLoopIV = linearVar;
+            break;
----------------
tblah wrote:

What if there are multiple stores from different variables to the IV? Codex gave me this example:
```
// x then y
omp.simd linear(%x : !llvm.ptr = %step : i32,
                %y : !llvm.ptr = %step : i32) {
  omp.loop_nest (%iv) : i32 = (%lb) to (%ub) step (%step) {
    llvm.store %iv, %x : i32, !llvm.ptr
    llvm.store %iv, %y : i32, !llvm.ptr
    omp.yield
  }
} {linear_var_types = [i32, i32]}
```

If x and y were flipped then the other one would be inferred as the linear result variable.

This is at least valid MLIR (if this can't be generated from Fortran maybe we need an MLIR verifier check to disallow this construction).

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