[PATCH] D79159: [MLIR] Add complex numbers to standard dialect

[Frederik Gossen via Phabricator via llvm-commits]

frgossen added inline comments.


================
Comment at: mlir/include/mlir/Dialect/StandardOps/IR/Ops.td:1013
+  let arguments = (ins AnyFloat:$real, AnyFloat:$imag);
+  let results = (outs Complex<AnyFloat>:$cplx);
+
----------------
ftynse wrote:
> Could we use a full word for the name, `$complex`. We generate functions with this name, it's more readable but reasonably short
Also changed `$imag` to `$imaginary`. 


================
Comment at: mlir/include/mlir/Dialect/StandardOps/IR/Ops.td:1016
+  let assemblyFormat = [{
+    $real `,` $imag attr-dict `:` type($real) `,` type($imag) `->` type($cplx)
+  }];
----------------
rriddle wrote:
> ftynse wrote:
> > frgossen wrote:
> > > ftynse wrote:
> > > > Do we want to support "mixed" types, e.g. f32, f64 -> complex<f64>?  If not, I would just keep the `type($cplx)` here.
> > > I would love to have only `type($cplx)` here. 
> > > The reason for the current format is that `tablegen` complained when I dropped the other types. 
> > > I can fix this with a hand-written parser and printer but before I do that I want to ask if this is also possible with the `assemblyFormat` thingy. 
> > > What is the elegant way to do this? 
> > Indeed, auto-generated printer and parser needs a way to resolve _all_ types and cannot do so in this case. Sometimes, it can rely on the traits like `SameOperandAndResultTypes`, but not here. Ideally, we would have some way of specifying "type deduction rules"... Until that exists, you will need printer and parser functions. To make life easier, you can just take those generated by mlir-tblgen today and amend them a bit to deduce the types.
> You can do that with `TypesMatchWith`, it was intended for this purpose..
Nice. Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79159/new/

https://reviews.llvm.org/D79159