[Mlir-commits] [mlir] Add a more complete example to mlir-reduce docs (PR #116085)

[llvmlistbot at llvm.org]

aidint wrote:

Hi @j2kun. I believe the reason the example here causes a segfault is *almost* the same as the problem mentioned in [this PR](https://github.com/llvm/llvm-project/pull/190560#issuecomment-4210319799). I say almost because here the culprit isn't a *trivially dead operation* being interesting, but that the pattern application folds `arith.fptosi` into a constant, basically removing `arith.fptosi` from the region. This is module after pattern application:

```mlir
module {
  func.func @func2() -> i32 {
    %c1_i32 = arith.constant 1 : i32
    %c2_i32 = arith.constant 2 : i32
    %cst = arith.constant 2.200000e+00 : f32
    %cst_0 = arith.constant 5.300000e+00 : f32
    %c3_i32 = arith.constant 3 : i32
    %cst_1 = arith.constant 7.500000e+00 : f32
    %c9_i32 = arith.constant 9 : i32
    %c6_i32 = arith.constant 6 : i32
    %c7_i32 = arith.constant 7 : i32
    %c13_i32 = arith.constant 13 : i32
    return %c13_i32 : i32
  }
}
``` 

This is because of the `GreedyRewriteConfig` instance has `fold = true` by default, so any application even without any patterns will fold constants. This causes the root of the reduction tree release its module, which then cause a segfault. This is the same thing that happens with trivially dead operations, and the PR I mentioned earlier solves this problem as well.

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