[Mlir-commits] [mlir] [mlir] Fix region simplification bug when later blocks use prior block argument values (PR #97960)

Mehdi Amini llvmlistbot at llvm.org
Tue Sep 3 16:37:46 PDT 2024


================
@@ -0,0 +1,33 @@
+// RUN: mlir-opt --canonicalize='enable-patterns=AnyPattern region-simplify=aggressive' %s | FileCheck %s
+
+// Perform merge checks without performing canonicalization prior to simplification
+
+// This test should not merge ^bb2 and ^bb5, despite the fact that they are
+// identical because %4 is used outside of ^bb2.
----------------
joker-eph wrote:

Right, my point is that the comment is misleading here.

What about this reduction of the test case:

```
module {
  func.func @nested_loop(%arg0: i32, %arg1: i32, %arg2: i32, %arg3: i32, %arg4: i32, %arg5: i1) {
  // Irreducible control-flow: enter the middle of the loop in LoopBody_entry here.
    "test.foo_br"(%arg0, %arg4)[^LoopBody_entry] : (i32, i32) -> ()

  // Loop exit condition: jump to exit or 
  ^Loop_header:  // 2 preds: ^bb2, ^bb3
    // Consumes the block arg from LoopBody_entry
    // Because of this use here, we can't merge the two blocks below.
    "test.foo_br2"(%0)[^EXIT, ^LoopBody_entry, ^LoopBody_other] : (i32) -> ()

  // LoopBody_entry is jumped in from the entry block (bb0) and Loop_header
  // It **dominates** the Loop_header.
  ^LoopBody_entry(%0: i32):  // 2 preds: ^bb0, ^Loop_header
   // CHECK: test.foo
    %1 = "test.foo"(%0) : (i32) -> i32
    cf.br ^Loop_header

  // Other block inside the loop, not dominating the header
  ^LoopBody_other(%2: i32):  // pred: ^Loop_header
   // CHECK: test.foo
    %3 = "test.foo"(%2) : (i32) -> i32
    cf.br ^Loop_header

  ^EXIT:  // pred: ^Loop_header
    return
  }
}
```


Seems to me that it's more minimal and also more clear: we actually check that the block merge does not happen here.

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


More information about the Mlir-commits mailing list