Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dialects: (arith) add SignlessIntegerBinaryOperation canonicalization #3583

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

alexarice
Copy link
Collaborator

Got bored of implementing various arith canonicalizations that all looked the same, so I've done a bunch of them generically in one go.

I've missed out a fair few methods (shifting operations in particular stand out) where I wasn't sure if the python operation agreed with the mlir operation.

@alexarice alexarice added the dialects Changes on the dialects label Dec 6, 2024
@alexarice alexarice self-assigned this Dec 6, 2024
@alexarice alexarice requested a review from kimxworrall December 6, 2024 14:33
Copy link

codecov bot commented Dec 6, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.71%. Comparing base (1f67b7d) to head (f20fea7).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3583      +/-   ##
==========================================
- Coverage   90.74%   90.71%   -0.03%     
==========================================
  Files         465      465              
  Lines       58755    58813      +58     
  Branches     5630     5630              
==========================================
+ Hits        53317    53354      +37     
- Misses       3997     4016      +19     
- Partials     1441     1443       +2     

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

@alexarice alexarice changed the title dialects: (arith) add generic canonicalization dialects: (arith) add SignlessIntegerBinaryOperation canonicalization Dec 6, 2024
@compor compor self-requested a review December 6, 2024 14:39
Copy link
Collaborator

@math-fehr math-fehr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

Comment on lines 202 to 220
@staticmethod
def is_right_unit(attr: AnyIntegerAttr) -> bool:
return False
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add documentation on that function?
Why is there a right in the name? It doesn't seem that it takes the left/right side into account?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i being a right unit means that x . i = x but we don't necessarily have i . x = x. See the shift operations for example

Comment on lines +442 to +460
@staticmethod
def is_right_unit(attr: AnyIntegerAttr) -> bool:
return attr == IntegerAttr(1, attr.type)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this one taking the type into account, but the one in Addi just checks the value?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The one here is just to work around that the unit for i1 multiplication is -1 and not 1. This doesn't matter in the 0 case which Addi has

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about it I'm not 100% sure this will work for si1

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@superlopuh is there a better way to do this check?

@math-fehr
Copy link
Collaborator

Btw, at some point we should define an interface for is_zero and is_unit.
Not the scope of this PR though

@superlopuh
Copy link
Member

is_unit is relative to the operation, though

@alexarice
Copy link
Collaborator Author

is_right_zero is also relative to the operation.

@alexarice
Copy link
Collaborator Author

I've realised that being a zero for a function might not be common terminology for non-mathematicians. Would it be preferable to rename this to is_right_absorbing or is_right_annihilating instead?

@superlopuh
Copy link
Member

Both of those seem more confusing 😅

@alexarice
Copy link
Collaborator Author

I've left the names the same but added docstrings. @math-fehr @superlopuh does this make sense?

Comment on lines +199 to +218
def is_right_zero(attr: AnyIntegerAttr) -> bool:
"""
Returns True only when 'attr' is a right zero for the operation
https://en.wikipedia.org/wiki/Absorbing_element

Note that this depends on the operation and does *not* imply that
attr.value.data == 0
"""
return False

@staticmethod
def is_right_unit(attr: AnyIntegerAttr) -> bool:
"""
Return True only when 'attr' is a right unit/identity for the operation
https://en.wikipedia.org/wiki/Identity_element
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ooh, if there are wikipedia pages with those titles then maybe using those for function names is fair game

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the wikipedia page for Absorbing element says that Absorbing element/annihilating element/zero are also used in various contexts

@alexarice alexarice force-pushed the alexarice/arith-canon branch from d883932 to 6e484a7 Compare December 9, 2024 18:57
@alexarice alexarice marked this pull request as draft December 10, 2024 09:15
@alexarice
Copy link
Collaborator Author

alexarice commented Dec 10, 2024

This suffers from a similar problem to #3585 . I'll try to work out the proper overflow semantics

@alexarice alexarice force-pushed the alexarice/arith-canon branch from 6e484a7 to bf6a5fa Compare December 12, 2024 22:03
@alexarice alexarice marked this pull request as ready for review December 12, 2024 22:03
@alexarice
Copy link
Collaborator Author

I've rebased, added an i1 test, and truncated the result of constant propagation to fix this case and keep in line with what mlir does.

Comment on lines 170 to 181
value: int | IntAttr,
value_type: int | IntegerType | IndexType,
*,
truncate_bits: bool = False,
) -> ConstantOp:
if isinstance(value_type, int):
value_type = IntegerType(value_type)
return ConstantOp.create(
result_types=[value_type],
properties={"value": IntegerAttr(value, value_type)},
properties={
"value": IntegerAttr(value, value_type, truncate_bits=truncate_bits)
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how do you feel about a quick separate PR for this guy?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alexarice added a commit that referenced this pull request Dec 13, 2024
@alexarice
Copy link
Collaborator Author

Should be ready for review again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dialects Changes on the dialects
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants