tree 8059844a7d8aae7436103ca7ff3cd91b0f2a79d9
parent 4e8c730fc23b3d007c3ed0a04573957a718df1d3
author Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> 1771880385 -0800
committer GitHub <noreply@github.com> 1771880385 +0000
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJpnL/BCRC1aQ7uu5UhlAAAbcQQAF+nPvzL1tjResHuz7mwbp94
 wxi3z74v4JM6pnRoccPek/RkRbWA7WPS1j19Fd2iH/zx0tqZVxZR9Rwpc/g+7i94
 7o7TvrJYhQk5hbat1PFKnN7AnKjclDXkWOL1eg+0UnTO8Xj4fR3M0ioCmoATvrw2
 x17zokgCl4iQWPVD+P1T/vvLg+YTR5xeIsc01a8AT6w7TfuuSlWIAaxRIGslasae
 X8LgWUx6cExAcDVFHDKGsO6gKUlq7M+qwLQZE3I4Q32oIo/skQHlBtsIhdMgQoFp
 RchBX4gLtP6o6FOnqBvwZ3EPSbTsVDmNYQdR01WrrCYCsl0L+nKidMW5FRWPZOg7
 qzWMgF4iEknToVbesR+abjkvn97ljotuc2EEkas0/Qj62Y5AdBGDT80yRKq7WDQN
 3sHtg4i4FTbn0qk9ITZabNqstTPVSLJ7GjtA5lfz5QVw+pShyRqtubUzOUzCYP/O
 FZkFppWOE8mFxAAyfDNIu4UvYG48ua1TC0liVUbUR+6dIi/8hThHSHnGjcCeSpTV
 6yUIQwKL7CSgwZRkmNW76eEUuH73NTMasGcblD94ACq4FGR8yqkErucdLesvqfRS
 OaUSl3tZhve6iWc6FlVZsp5o7v3EyZhVt195Ic7+Ut6IEyfpexYIWS06g9apoZA4
 zw4/sZQQoO46lCOCzvpg
 =W7Pb
 -----END PGP SIGNATURE-----
 

[flang] Restrict mem2reg promotion through fir.declare to single-block case (#182933)

The PromotableOpInterface on fir.declare allows mem2reg to promote
allocas accessed through declare ops. However, MLIR's mem2reg computes
defining blocks and live-in sets only from direct users of the slot
pointer. Stores through fir.declare are users of the declare result, not
the alloca, so they are not registered as defining blocks. This causes
missing phi nodes at join points (loop headers, merge blocks), which
silently drops conditional updates to promoted variables.
This was observed in CUDA Fortran kernels where a loop variable updated
conditionally (e.g., mywatch = max(1, mywatch-32)) became constant after
promotion, producing incorrect results at runtime.
The fix restricts promotion through fir.declare to cases where all users
of the declare are in the same block. In single-block cases no phi nodes
are needed, so the MLIR limitation does not apply. Cross-block cases are
left unpromoted until the MLIR mem2reg infrastructure is extended to
track defining blocks through PromotableOpInterface results.

With the current behavior, this would be the result. 
```
func.func @loop_conditional_update(%arg0: i32, %cdt: i1) -> i32 {
  %c1 = arith.constant 1 : i32
  %alloca = fir.alloca i32 {bindc_name = "mywatch", uniq_name = "_QFkernelEmywatch"}
  %declare = fir.declare %alloca {uniq_name = "_QFkernelEmywatch"} : (!fir.ref<i32>) -> !fir.ref<i32>
  fir.store %arg0 to %declare : !fir.ref<i32>
  llvm.br ^loop
^loop:
  %val = fir.load %declare : !fir.ref<i32>
  llvm.cond_br %cdt, ^update, ^exit
^update:
  %new = arith.subi %val, %c1 : i32
  fir.store %new to %declare : !fir.ref<i32>
  llvm.br ^loop
^exit:
  %result = fir.load %declare : !fir.ref<i32>
  return %result : i32
}
```

```
  func.func @loop_conditional_update(%arg0: i32, %arg1: i1) -> i32 {
    %c1_i32 = arith.constant 1 : i32
    fir.declare_value %arg0 {uniq_name = "_QFkernelEmywatch"} : i32
    llvm.br ^bb1
  ^bb1:  // 2 preds: ^bb0, ^bb2
    llvm.cond_br %arg1, ^bb2, ^bb3
  ^bb2:  // pred: ^bb1
    %0 = arith.subi %arg0, %c1_i32 : i32 // Doesn't use current value. 
    fir.declare_value %0 {uniq_name = "_QFkernelEmywatch"} : i32
    llvm.br ^bb1
  ^bb3:  // pred: ^bb1
    return %arg0 : i32 // always return $arg0
  }
```

A better fix should probably be done in mem2reg to support these cases
better. I'll look into that later this week.