[Mlir-commits] [mlir] [MLIR] Erase unreachable blocks before applying patterns in the greedy rewriter (PR #153957)

Mehdi Amini llvmlistbot at llvm.org
Sat Aug 16 11:35:26 PDT 2025


================
@@ -3363,3 +3363,18 @@ func.func @bf16_fma(%arg0: vector<32x32x32xbf16>, %arg1: vector<32x32x32xbf16>,
     }
   }
 #-}
+
+// CHECK-LABEL: func @unreachable()
+// CHECK-NEXT: return
+// CHECK-NOT: arith
+func.func @unreachable() {
+  return
+^unreachable:
+  %c1_i64 = arith.constant 1 : i64
+  // This self referencing operation is legal in an unreachable block.
+  // Many patterns are unsafe with respect to this kind of situation,
+  // check that we don't infinite loop here.
+  %add = arith.addi %add, %c1_i64 : i64
----------------
joker-eph wrote:

> I don't follow. When you do a local transformation, you don't know that you are operating on unreachable IR. 

Exactly, so you don't know you would violate things.
For example the "self-referencing operation can be created from folding the second add here:

```
^unreachable(%arg : i64):
  %add = arith.addi %add_plus_zero, %c1_i64 : i64
  %add_plus_zero  = arith.addi %arg, %c0_i64 : i64
  cf.cond_br %cond  ^unreachable, ^other
```

The folder would just do RAUW here.
Of course no one builds the IR that way, but you start with a CFG which has blocks which are dynamically unreachable, then you propagate some constants, simplify some branches, end up with some unreachable blocks, and after more simplification you end up here.

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


More information about the Mlir-commits mailing list