This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Add sin & cos ops to complex dialect
ClosedPublic

Authored by gflegar on May 2 2022, 7:56 AM.

Details

Summary

Also add conversions for those ops to math + arith.

Diff Detail

Event Timeline

gflegar created this revision.May 2 2022, 7:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 2 2022, 7:56 AM
gflegar requested review of this revision.May 2 2022, 7:56 AM

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.
This is a bit risky though in that you create these ops no matter if the values are used or not.
You could extract these as functions to be used on demand.

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.
see https://llvm.org/docs/CommandGuide/FileCheck.html#the-check-dag-directive

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

frgossen added inline comments.May 3 2022, 8:05 AM
mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp
135

Can we keep things simple and use a "normal" virtual function here to avoid the templating?

gflegar added inline comments.May 3 2022, 8:46 AM
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:

  1. ending up just creating simple wrappers around rewriter.create<Op>, which defeats the whole purpose, and ends up having the same amount of code duplication, or
  2. duplicating the same instructions multiple times, since the end products we care about (scaledExp, reciprocalExp, sin, cos) share the same intermediate values, or
  3. ending up with more complex code that tries to avoid generating intermediate values multiple times, which I again think is not worth the effort.

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.

gflegar added inline comments.May 3 2022, 9:15 AM
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:

Why use CHECK-DAG for everything else, but not for return.

The rule of thumb we came up with would be:

Prefer CHECK, unless the order of operations could reasonably change without impacting the correctness of the test. In that case, use CHECK-DAG instead.

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:

Use CHECK-DAG for "expressions", and CHECK for "statements".

frgossen added inline comments.May 3 2022, 9:18 AM
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.

gflegar marked 2 inline comments as done.May 3 2022, 9:20 AM
gflegar added inline comments.
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.

gflegar added inline comments.May 3 2022, 9:21 AM
mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp
124

exp as well

gflegar marked an inline comment as done.May 3 2022, 9:21 AM
gflegar updated this revision to Diff 426752.May 3 2022, 9:53 AM

Make combine a regular function, use CHECK-DAG, formatting

gflegar marked 6 inline comments as done.May 3 2022, 9:55 AM
frgossen accepted this revision.May 3 2022, 10:18 AM

Awesome, thanks!!

mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp
155

super-nit: redundant brackets?

663

super-nit: brackets?

mlir/test/Conversion/ComplexToStandard/convert-to-standard.mlir
51

super-nit: adding some spaces between CHECK and return can make this easier to read

This revision is now accepted and ready to land.May 3 2022, 10:18 AM
gflegar marked 2 inline comments as done.May 3 2022, 10:22 AM
gflegar added inline comments.
mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp
155

I don't see any redundant ones, which ones do you think are redundant?

663

same as above

gflegar updated this revision to Diff 426764.May 3 2022, 10:27 AM
gflegar marked 2 inline comments as done.

Minor formatting

gflegar marked an inline comment as done.May 3 2022, 10:29 AM
This revision was landed with ongoing or failed builds.May 3 2022, 10:37 AM
This revision was automatically updated to reflect the committed changes.