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: (math) Add support for custom format and container types to math dialect ops #3786

Merged
merged 21 commits into from
Jan 25, 2025

Conversation

compor
Copy link
Collaborator

@compor compor commented Jan 24, 2025

This PR:

  • Adds support for custom format
  • Adds support for container types in the operands and results of the relevant ops (e.g., tensor)
  • Tests (including interoperability) of the above

Resolves: #3739, #2739

@compor compor added the dialects Changes on the dialects label Jan 24, 2025
@compor compor self-assigned this Jan 24, 2025
Copy link

codecov bot commented Jan 24, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.23%. Comparing base (bac3115) to head (eb354c6).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3786      +/-   ##
==========================================
- Coverage   91.25%   91.23%   -0.03%     
==========================================
  Files         461      461              
  Lines       57594    57446     -148     
  Branches     5546     5546              
==========================================
- Hits        52560    52411     -149     
- Misses       3611     3612       +1     
  Partials     1423     1423              

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

@@ -529,12 +462,18 @@ class FPowIOp(IRDLOperation):
"""

name = "math.fpowi"

T1: ClassVar = VarConstraint("T1", floatingPointLike)
T2: ClassVar = VarConstraint("T2", signlessIntegerLike)
Copy link
Member

Choose a reason for hiding this comment

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

seems unnecessary, although I guess it doesn't hurt much

Copy link
Collaborator

Choose a reason for hiding this comment

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

I agree, there's no reason to have this variable

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'll amend, it's a leftover from reusing the base classes.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It seems like the assembly format cannot infer the type of result

type of result 'result' cannot be inferred, consider adding a 'type($result)' directive to the custom assembly format

Hence, I ended up keep one of them.

@@ -529,12 +462,18 @@ class FPowIOp(IRDLOperation):
"""

name = "math.fpowi"

T1: ClassVar = VarConstraint("T1", floatingPointLike)
T2: ClassVar = VarConstraint("T2", signlessIntegerLike)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I agree, there's no reason to have this variable


T1: ClassVar = VarConstraint("T1", floatingPointLike)
T2: ClassVar = VarConstraint("T2", signlessIntegerLike)

fastmath = opt_prop_def(FastMathFlagsAttr)
Copy link
Collaborator

Choose a reason for hiding this comment

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

A lot of the other fastmath flags in mlir are default valued props instead of optional props. Is the math dialect different?

Copy link
Collaborator Author

@compor compor Jan 25, 2025

Choose a reason for hiding this comment

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

What do you mean by "a lot"? Our arith and llvm dialect uses of the flags differ, but the net result is the same, as absence means none.

I'll check MLIR later and amend in a separate PR just for the flags as required.
I also wanted to check the relevant interface, so another incentive to do so.

@compor compor merged commit 6fd4792 into main Jan 25, 2025
16 checks passed
@compor compor deleted the christos/dialects/math/custom-format branch January 25, 2025 13:25
oluwatimilehin pushed a commit to oluwatimilehin/xdsl that referenced this pull request Feb 13, 2025
… `math` dialect ops (xdslproject#3786)

This PR:

- Adds support for custom format
- Adds support for container types in the operands and results of the
relevant ops (e.g., `tensor`)
- Tests (including interoperability) of the above

Resolves: xdslproject#3739, xdslproject#2739
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.

dialects: (math) Several ops do not accepts vector or tensor types, but their MLIR counterparts do
3 participants