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: (builtin) Fix printing and parsing of UnitAttr #2744

Merged
merged 6 commits into from
Jun 19, 2024

Conversation

superlopuh
Copy link
Member

It's actually unit not the empty string.

@superlopuh superlopuh added the dialects Changes on the dialects label Jun 17, 2024
@superlopuh superlopuh self-assigned this Jun 17, 2024
@@ -1250,6 +1250,7 @@ def _parse_optional_integer_or_float_type(self) -> Attribute | None:
Parse as integer or float type, if present.
integer-or-float-type ::= index-type | integer-type | float-type
index-type ::= `index`
unit-attribute ::= `unit`
Copy link
Member Author

Choose a reason for hiding this comment

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

I first tried to add this as a normal attribute not type, but then the test failed, saying "type expected". I have a supsicion it's actually a type in MLIR also, but my quick search for the definition didn't yield much so I thought I'd open a PR anyway.

Copy link
Collaborator

Choose a reason for hiding this comment

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

It is not a type, it's an attribute though: https://mlir.llvm.org/docs/Dialects/Builtin/#unitattr

Copy link
Member Author

Choose a reason for hiding this comment

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

Should I change the test instead? When I put the code for parsing into parse_attribute it fails, as the block argument expects a type.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Which test? And yes, we should change it I think

Copy link

codecov bot commented Jun 17, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.77%. Comparing base (e329816) to head (3e026a4).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2744      +/-   ##
==========================================
- Coverage   89.78%   89.77%   -0.01%     
==========================================
  Files         370      370              
  Lines       47617    47626       +9     
  Branches     7299     7301       +2     
==========================================
+ Hits        42751    42758       +7     
- Misses       3730     3731       +1     
- Partials     1136     1137       +1     

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

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.

Thanks for looking at this!
unit is an attribute, not a type in MLIR, and we should stay the same.
So here I would not add it in the parse_optional_integer_or_float_type

Comment on lines 1266 to 1270
# Unit type
if name == "unit":
self._consume_token()
return UnitAttr()

Copy link
Collaborator

Choose a reason for hiding this comment

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

This is not the right place to add this though, this is neither an integer nor attribute type?

@superlopuh superlopuh requested a review from math-fehr June 18, 2024 08:43
Copy link
Collaborator

@AntonLydike AntonLydike left a comment

Choose a reason for hiding this comment

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

LGTM, just some small misc. comments

@@ -8,6 +8,9 @@

// CHECK: (index)

"func.func"() ({}) {function_type = () -> (), sym_name = "unit_attr_func", unitarray = [unit]} : () -> ()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can I suggest using the test dialect here? I don't think we want to depend on func here...

Copy link
Member Author

Choose a reason for hiding this comment

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

I agree in general, although here it seemed like a good fit for consistency, happy to change it if you or anyone else insist

"""
if self._current_token.kind != Token.Kind.BARE_IDENT:
return None
name = self._current_token.span.text
Copy link
Collaborator

Choose a reason for hiding this comment

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

supernit: Not sure this extra variable assignment is needed here?

Copy link
Member Author

Choose a reason for hiding this comment

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

definitely not, although it doesn't really hurt either

Copy link
Collaborator

@PapyChacal PapyChacal left a comment

Choose a reason for hiding this comment

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

Seeing the low footprint, I'm guessing this preserves the behaviour of unit attribute being printed as "just a name" in attribute dictionaries?

I had no clue they were handled otherwise in other places 😃

xdsl/parser/attribute_parser.py Outdated Show resolved Hide resolved
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.

Looks good to me now (I would just fix the comment that Emilien pointed)

superlopuh and others added 2 commits June 19, 2024 12:17
Co-authored-by: Emilien Bauer <papychacal@gmail.com>
@superlopuh superlopuh merged commit 79eeff0 into main Jun 19, 2024
10 checks passed
@superlopuh superlopuh deleted the sasha/builtin/unit branch June 19, 2024 12:17
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.

5 participants