[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