dialects: (complex) add folding canonicalization pattern

[radosavkrunic33]

This PR folds complex floating point binary ops whose operands are both complex.constants.
The complex binary ops that support folding are add, sub, mul, div.

It's a split-out PR from @#5440.

[codecov]

Codecov Report

❌ Patch coverage is 38.33333% with 37 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.19%. Comparing base (39d56e0) to head (d4b7a19).
⚠️ Report is 11 commits behind head on main.

Files with missing lines	Patch %	Lines
xdsl/dialects/complex.py	38.33%	37 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5497   +/-   ##
=======================================
  Coverage   86.18%   86.19%           
=======================================
  Files         399      399           
  Lines       56570    56627   +57     
  Branches     6510     6518    +8     
=======================================
+ Hits        48754    48808   +54     
- Misses       6282     6296   +14     
+ Partials     1534     1523   -11     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[superlopuh]

Hi @radosavkrunic33, sorry about the delay, we finally merged that branch, let's revisit this when you have time?

[radosavkrunic33]

Yes, I'll do it. Thank you for reminding me.

[superlopuh]

What's the error if you remove the cast?

[radosavkrunic33]

There is no error :)

[superlopuh]

Great, I would have been surprised, let's remove it in that case?

[superlopuh]

This is all unexpected and worth a comment IMO. Where are these results defined? I would have expected division by 0 to be undefined by default.

If we are sure that this is the expected result, it seems a bit more straightforward to define it this way, what do you think?

Suggested change

	if im_lhs == 0.0:
	imag = float("nan")
	else:
	if math.copysign(im_lhs, im_rhs) > 0:
	positive = True if im_lhs > 0 else False
	else:
	positive = True if im_lhs < 0 else False
	imag = float("inf") if positive else float("-inf")
	inf = float("inf") # or _INF at top of file maybe, same for nan
	if im_lhs == 0.0:
	imag = float("nan")
	else:
	# Positive infinity if signs match, negative otherwise
	imag = math.copysign(inf, im_lhs) / math.copysign(1.0, im_rhs)

[radosavkrunic33]

For integer, division by 0 is undefined behavior. For floating-point division, the IEEE‑754 standard defines the behavior-https://en.wikipedia.org/wiki/Division_by_zero#:~:text=Floating-point%20arithmetic,-In%20computing%2C%20most&text=A%20NaN%20(not%20a%20number,same%20sign%20as%20the%20dividend. .MLIR follows IEEE754 specification for floating-point arithmetic. Please, correct me if I'm wrong. A related discussion can be found here.

[superlopuh]

Can you please add a lit test for each of the patterns added?

[radosavkrunic33]

I tested all these patterns locally by setting folding_enabled = True in GreedyRewritePatternApplier within CanonicalizePass. Would it be good to enable folding for all canonicalization patterns, so that we can add these lit tests?

When folding is enabled for all canonicalization patterns and all lit tests are run, an issue occurs with tests/filecheck/dialects/arith/canonicalize.mlir. Trying to fold %11 = arith.constant true; %12 = arith.addi %11, %11 : i1 causes an error; %12 is out of range for the i1 type.

[superlopuh]

I think that would make sense, and I'm not sure what the expected behaviour of adding two Trues is. @math-fehr ?

[math-fehr]

true is a shorthand for -1, so here adding two -1 should be -2.
Then, because it is an i1, you need to handle the overflow, so you should have 0.

[superlopuh]

@osmanyasar05, I'll try to enable folding soon and get back to you on this, I just ran this locally and there are some more errors that shouldn't be fixed in this PR anyway.

[superlopuh]

I just wanted to write here that I'm making good progress on fixing the required changes that need to be made in the backend dialects to support this, it was much worse than I initially estimated.