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

[Jeremy Kun]

j2kun 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 of patterns even with an empty patternset will fold constants. This causes the root of the reduction tree to 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.

Thanks! I stopped thinking about this tool a while back, but if you see a simple tweak of my PR that will cause it to work (maybe replacing the interesting op with one that doesn't fold away and isn't dead?) then I can update this PR.

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