[all-commits] [llvm/llvm-project] c14ba3: [mlir] Fix block merging with the result of a term...

[zero9178 via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c14ba3c4be09348cb5e796d000bfa62fba931ae8
      https://github.com/llvm/llvm-project/commit/c14ba3c4be09348cb5e796d000bfa62fba931ae8
  Author: Markus Böck <markus.boeck02 at gmail.com>
  Date:   2022-03-21 (Mon, 21 Mar 2022)

  Changed paths:
    M mlir/lib/Transforms/Utils/RegionUtils.cpp
    M mlir/test/Transforms/canonicalize-block-merge.mlir
    M mlir/test/lib/Dialect/Test/TestDialect.cpp
    M mlir/test/lib/Dialect/Test/TestOps.td

  Log Message:
  -----------
  [mlir] Fix block merging with the result of a terminator

When the current implementation merges two blocks that have operands defined outside of their block respectively, it will merge these by adding a block argument in the resulting merged block and adding successor arguments to the predecessors.
There is a special case where this is incorrect however: If one of predecessors terminator produce the operand, inserting the block argument and updating the predecessor would lead to the terminator using its own result as successor argument.
IR Example:
```
  %0 = "test.producing_br"()[^bb1, ^bb2] {
        operand_segment_sizes = dense<0> : vector<2 x i32>
	} : () -> i32

^bb1:
  "test.br"(%0)[^bb4] : (i32) -> ()
```
where `^bb1` is then merged with another block would lead to:
 ```
  %0 = "test.producing_br"(%0)[^bb1, ^bb2]
```

This patch fixes that issue during clustering by making sure that if the operand is from an outside block, that it is not produced by the terminator of a predecessor.

Differential Revision: https://reviews.llvm.org/D121988