Add CreateComplexOp, ReOp, and ImOp to the standard dialect.
This is the first step to support complex numbers.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/test/mlir-cpu-runner/complex_numbers.mlir | ||
---|---|---|
7 | I double-checked the output of mlir-opt %s -convert-std-to-llvm | mlir-cpu-runner -e create_and_extract_real -entry-point-result=f32 and it is no more than the result of the computation, i.e. 1.200000e+00. | |
22 | See above. |
Looks good in general! I have some advice on the op syntax, feel free to argue against it.
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
1013 | Could we use a full word for the name, $complex. We generate functions with this name, it's more readable but reasonably short | |
1016 | Do we want to support "mixed" types, e.g. f32, f64 -> complex<f64>? If not, I would just keep the type($cplx) here. | |
1528 | This example looks wrong: the spec below says there is only one operand | |
1536 | I think complex<X> -> X is quite redundant here, keeping just the complex type should suffice. | |
1939 | Same as above | |
mlir/lib/Conversion/StandardToLLVM/StandardToLLVM.cpp | ||
197 | I think you can just call convertType(type.getElementType()) and let it be dispatched for you. | |
1299 | We tend to use the kRealIdxInCpxNumStruct style for constants. | |
1312 | Could you rather derive a new ComplexStructBuilder from `StructBuilder and use it here? Look at MemRefDescriptor for an example. | |
mlir/lib/Dialect/StandardOps/IR/Ops.cpp | ||
1230 | Could you please add a test for this? test/IR/invalid-ops.mlir sounds like the right file (although the file itself is misplaced) | |
mlir/test/Conversion/StandardToLLVM/convert-to-llvmir.mlir | ||
78 | You don't need an explicit label for the entry block in MLIR functions (and most other operations) | |
mlir/test/mlir-cpu-runner/complex_numbers.mlir | ||
1 | I think the conversion is straightforward enough to trust the individual components and drop this test. The -runner tests are intended to check that the runner itself works, your patch does not alter it in any way. |
Thanks for the many helpful comments.
There is one comment for which I'd like clarification.
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
1016 | I would love to have only type($cplx) here. |
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
1016 | 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. |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
18 | Please use forward declarations instead of includes in header files when you can. | |
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
996 | Same comment as below. | |
1016 | You can do that with TypesMatchWith, it was intended for this purpose.. | |
1516 | Don't provide a syntax if you have the declarative assembly(assemblyFormat). It is included automatically in the docs. | |
1927 | Same here. | |
mlir/lib/Dialect/StandardOps/IR/Ops.cpp | ||
1228 | You should be able to verify this in tablegen with TypesMatchWith. | |
1649 | Same comment as the other verifier. | |
1905 | Same here. |
Thanks!
mlir/include/mlir/Dialect/StandardOps/EDSC/Intrinsics.h | ||
---|---|---|
34 | Nit: let's use std_re to be consistent with the assembly spelling. | |
mlir/test/IR/invalid-ops.mlir | ||
1236 ↗ | (On Diff #261766) | Nit: let's not hardcode SSA value names in checks, I think it's fine to shorten the expected-error message to expects different type than prior uses: 'f32' vs 'f64' |
Please use forward declarations instead of includes in header files when you can.