[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