Also add conversions for those ops to math + arith.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Awesome! Thank you!
mlir/include/mlir/Dialect/Complex/IR/ComplexOps.td | ||
---|---|---|
116 | It's correct but it got me wondering if the base classes could use some cleaning up, i.e. if we want to have something like ComplexArithmeticOp for unary and binary. Could be a separate CL | |
mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp | ||
124 | Very nice to extract these building blocks. | |
153 | nit: maybe indent the equations | |
664 | nit: maybe indentation | |
mlir/test/Conversion/ComplexToStandard/convert-to-standard.mlir | ||
38 | Where the order of the ops does not matter, you can use CHECK-DAG. Here, you can use it everywhee except for the return op. | |
51 | nit: in the interest of readability, you don't need to check the types everywhere but only where it is non-obvious. | |
384 | Same as above |
mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp | ||
---|---|---|
135 | Can we keep things simple and use a "normal" virtual function here to avoid the templating? |
mlir/include/mlir/Dialect/Complex/IR/ComplexOps.td | ||
---|---|---|
116 | I guess we could remove the repetitions of SameOperandsAndResultType, and let results = .... Could be a minor cleanup, but would definitely better fit into a separate CL. | |
mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp | ||
124 | I did have that consideration as well, but the thing is that so far we are using all of these components in both cases. We can always refactor later if we need something different, especially since this is not a part of a public interface. With splitting this up into separate functions we are risking one of the following:
I guess you can also make the case that if we went either for the current approach, or (2), the inefficiencies generated by both (though, I want to note again, that for our current use-case, there is no inefficiency with the current approach) could easily be eliminated by subsequent passes (DCE, and CSE respectively), and (3) would just implement a limited subset of such a pass. |
mlir/test/Conversion/ComplexToStandard/convert-to-standard.mlir | ||
---|---|---|
38 | Synced offline with frgossen about this, so documenting the summary here in case anyone else has the same question as I did:
The rule of thumb we came up with would be:
Note that applying this rule would also support using CHECK for the final complex.create op, but that starts requiring thinking about the dependencies, so a good heuristic without going that deep is:
|
mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp | ||
---|---|---|
124 | Didn't see the reuse of half. Let's keep it simple like this not to rely on CSE. |
mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp | ||
---|---|---|
135 | My original thinking was to allow the compiler to inline this call and optimize it better. Though that probably does not make a big difference here. |
mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp | ||
---|---|---|
124 | exp as well |
It's correct but it got me wondering if the base classes could use some cleaning up, i.e. if we want to have something like ComplexArithmeticOp for unary and binary. Could be a separate CL