[Mlir-commits] [mlir] [mlir][Transforms] Dialect conversion: Simplify handling of dropped arguments (PR #96207)
Matthias Springer
llvmlistbot at llvm.org
Sun Jun 30 08:09:58 PDT 2024
matthias-springer wrote:
I debugged this a bit. There is a bug in the dialect conversion driver. It was already broken before, but broken in a different way. Before this PR, let's take this input IR which is similar to yours:
```
func.func @reproducer() -> !llvm.struct<(f64, f64)> {
%cst = complex.constant [0.000000e+00, 0.000000e+00] : complex<f64>
%true = arith.constant true
%0 = scf.if %true -> complex<f64> {
scf.yield %cst : complex<f64>
} else {
scf.yield %cst : complex<f64>
}
%1 = "test.foo"(%0) : (complex<f64>) -> (!llvm.struct<(f64, f64)>)
return %1 : !llvm.struct<(f64, f64)>
}
```
The `test.foo` op is rewritten as follows:
```
...
^bb3(%1: !llvm.struct<(f64, f64)>): // 2 preds: ^bb1, ^bb2
llvm.br ^bb4
^bb4: // pred: ^bb3
%2 = "test.foo"(%1) : (!llvm.struct<(f64, f64)>) -> !llvm.struct<(f64, f64)>
llvm.return %2 : !llvm.struct<(f64, f64)>
}
```
That's wrong, we can't just change the type of the `"test.foo"` operand without inserting a cast. (For a `builtin.unrealized_conversion_cast`, it happens to work.) Probably the meaning of an argument materialization must be changed. It should map from the new "N" replacement types to the old type.
https://github.com/llvm/llvm-project/pull/96207
More information about the Mlir-commits
mailing list