This is part of splitting the std dialect. Dialect Scope and Goal The complex dialect is intended to hold complex numbers creation and arithmetic ops. The following ops will be moved to ComplexOps.td: std.create_complex → complex.create std.im → complex.im std.re → complex.re std.addcf → complex.addf std.subcf → complex.subf Examples of future additions to the complex dialect could be: compex.conj complex.divf complex.mulf Development process The split will be done in two steps Create complex dialect without removing complex ops from std Remove complex ops from std after TensorFlow has migrated to the ones in complex

[image] pifon2a: Create complex dialect without removing complex ops from std Remove complex ops from std after TensorFlow has migrated to the ones in complex It isn’t clear to me why upstream development should be driven specifically to fit the need of TensorFlow in particular. I’m not fond of this kind of rational to drive upstream development in general and the kind of precedent this sets. Otherwise +1 for the split overall!

[image] mehdi_amini: TensorFlow in particular. That’s a good point. I’m assuming Alex meant to give downstream users time to update (not sure how much easier it would make it though as you have all the matching rules and C++ class usage, passes upstream and downstream that consumes or produces them, but perhaps there is some aliases or typedeffing that could simplify it). Perhaps just say a week/two weeks post split independent on whether who changed what where?

Me neither, it could be useful but I’m not sure anyone does (but I’m biased, I think of complex numbers as ordered pair of real numbers).

[image] mehdi_amini: I’m not fond of this kind of rational to drive upstream development in general and the kind of precedent this sets. I’m not fond of the rationale phrasing but as someone with a couple of downstream projects, I do like the aim in sequencing large breaking changes incrementally. Perhaps this can be fixed with a rephrase: Remove complex ops from std after giving downstream projects time to migrate (I work on tensorflow and we estimate that X weeks would be helpful as a compatibility window).

Absolutely! This is how I proceeded with the revamp of the dialect registration for example. We shouldn’t put an expectation that every change will be done incrementally though: I’m supporting it only if it is easier to develop and review (or at least does not make it harder to achieve upstream).

This will only affect the listed Ops, correct? And not the type? (Just checking. Thanks in advance.)

@schweitz Yes, the type won’t be affected.

@stellaraccident Thanks for the rephrase! @mehdi_amini Agree with everything above. Doing this split incrementally definitely won’t make it harder to develop or review in this particular case. But it would make life a bit easier for the downstream projects.

Would it make sense then to assume that the complex type always has real element type, unless explicitly specified? I would drop ‘f’ in the op names, i.e. complex.sub not complex.subf.

[RFC] Split the `complex` dialect from `std`

MLIR

pifon2a December 30, 2020, 3:40pm 2

ComplexType allows integer element type. I am not aware if anyone would ever need that.

Topic		Replies	Views
Dialect for complex numbers? MLIR	13	1728	February 28, 2022
[RFC] Splitting the Standard dialect MLIR	13	3669	December 5, 2020
[RFC] Split the `int` and `float` dialects from `std` MLIR	45	2677	October 8, 2021
[Standard] Add `atan2` to the standard dialect MLIR	29	2341	September 29, 2020
[RFC] Split the math `dialect` from `std` MLIR	6	858	February 12, 2021

[RFC] Split the `complex` dialect from `std`

Related topics