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) normalize signless values on init #3554

Merged
merged 12 commits into from
Dec 6, 2024

Conversation

superlopuh
Copy link
Member

@superlopuh superlopuh commented Dec 2, 2024

Follows MLIR behaviour.

@superlopuh superlopuh added the dialects Changes on the dialects label Dec 2, 2024
@superlopuh superlopuh self-assigned this Dec 2, 2024
Copy link
Collaborator

@jorendumoulin jorendumoulin 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 1005 to 1051
if any(signed_ub <= attr.data for attr in attr_list):
attr_list = tuple(
IntAttr(data_type.normalize_value(attr.data)) for attr in attr_list
)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there any harm in just doing this every time? Otherwise I would think an additional check for too negative numbers is also required.

Copy link
Collaborator

Choose a reason for hiding this comment

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

an extra filecheck for this case is maybe also needed

Copy link
Member Author

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 doing it every time?

Copy link
Collaborator

Choose a reason for hiding this comment

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

omit this check: if any(signed_ub <= attr.data for attr in attr_list):

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, isn't normalize_value doing the same checks anyway?

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 generally dislike the idea of constructors being written in a way that doesn't allow the user to pass in correct data that is not copied/transformed in some way. I'll rewrite this part to conditionally normalize but return the original IntAttr if there's nothing to change.

@@ -649,7 +649,7 @@ csl.func @builtins() {
// CHECK-NEXT: return;
// CHECK-NEXT: }
// CHECK-NEXT: comptime {
// CHECK-NEXT: @bind_control_task(control_task, @get_control_task_id(42));
// CHECK-NEXT: @bind_control_task(control_task, @get_control_task_id(-22));
Copy link
Member Author

Choose a reason for hiding this comment

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

@n-io, will this still work? Should the values here be always printed as positive integers by the csl printer?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Not quite sure about this change? It should prob not print negative values.

Copy link
Member Author

@superlopuh superlopuh Dec 2, 2024

Choose a reason for hiding this comment

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

OK I'll attempt to fix the CSL printer then, as the signless before this change may already be in the negative range.

Copy link

codecov bot commented Dec 2, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.40%. Comparing base (dd58ef0) to head (c75d736).
Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #3554   +/-   ##
=======================================
  Coverage   90.40%   90.40%           
=======================================
  Files         469      469           
  Lines       58907    58941   +34     
  Branches     5605     5611    +6     
=======================================
+ Hits        53252    53287   +35     
  Misses       4213     4213           
+ Partials     1442     1441    -1     

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

Copy link
Collaborator

@alexarice alexarice left a comment

Choose a reason for hiding this comment

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

I think this likely subtly changes a number of existing passes, which compare integers by grabbing the data out of an IntegerAttr. I've caught one in the cf canonicalization patterns but I'm not what can be done to catch this in general.

@@ -58,6 +60,51 @@ def test_IntegerType_size():
assert IntegerType(64).size == 8


def test_IntegerType_normalize():
s8 = IntegerType(8, Signedness.SIGNED)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Extreme nit but I believe si is usually used in mlir as a prefix for signed integers

Copy link
Member Author

Choose a reason for hiding this comment

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

oh this is great, I couldn't remember it, and it's not in the IntegerAttr doc, of course


assert s8.normalize_value(-1) == -1
assert s8.normalize_value(1) == 1
assert s8.normalize_value(255) == 255
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not sure I understand the semantics here, do we not change values that fall outside the range?

Copy link
Member Author

@superlopuh superlopuh Dec 2, 2024

Choose a reason for hiding this comment

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

Yep, and your comment means that I should have documented this better: the idea is that we want to first preserve the behaviour for invalid integers, to raise a VerifyException with the invalid value. If the valid value is ambiguous due to signlessness, only then normalize to the signed range. I'll add this somewhere.

  • add more explanation to doc comment

return value

signed_ub = signed_upper_bound(self.bitwidth)
unsigned_ub = signed_ub << 1
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
unsigned_ub = signed_ub << 1
unsigned_ub = unsigned_upper_bound(self.bitwidth)

Why not use this? There will be complications with i0 right?

Copy link
Member Author

Choose a reason for hiding this comment

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

not really, this was a micro-optimisation, but I guess not really very important

rewriter.replace_matched_op(cf.BranchOp(op.then_block, *op.then_arguments))
elif cond == 0:
else:
rewriter.replace_matched_op(cf.BranchOp(op.else_block, *op.else_arguments))
Copy link
Collaborator

Choose a reason for hiding this comment

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

I can't work out how to attach the comment in the correct place but line 374 of this file will now be incorrect

Comment on lines 1005 to 1051
if any(signed_ub <= attr.data for attr in attr_list):
attr_list = tuple(
IntAttr(data_type.normalize_value(attr.data)) for attr in attr_list
)
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, isn't normalize_value doing the same checks anyway?

@superlopuh superlopuh force-pushed the sasha/builtin/normalise-value branch from 9261fe6 to 6609edb Compare December 2, 2024 15:20
@superlopuh superlopuh changed the base branch from sasha/builtin/0-bitwidth-ranges to sasha/builtin/print-i1 December 2, 2024 15:20
@superlopuh superlopuh marked this pull request as draft December 2, 2024 16:03
@superlopuh
Copy link
Member Author

I'm converting to draft as this seems like quite large a change, I'll split this up further by the seemingly unrelated things that are failing.

@superlopuh superlopuh force-pushed the sasha/builtin/print-i1 branch from 035fc8a to 061e87c Compare December 2, 2024 16:14
@superlopuh superlopuh force-pushed the sasha/builtin/normalise-value branch from 9de5b32 to f2d97a7 Compare December 2, 2024 16:14
Base automatically changed from sasha/builtin/print-i1 to main December 2, 2024 17:04
@superlopuh superlopuh force-pushed the sasha/builtin/normalise-value branch from f2d97a7 to bbda01f Compare December 2, 2024 17:13
@superlopuh superlopuh changed the base branch from main to sasha/builtin/py-value December 2, 2024 17:13
Base automatically changed from sasha/builtin/py-value to main December 5, 2024 08:29
@superlopuh superlopuh marked this pull request as ready for review December 5, 2024 16:08
@superlopuh superlopuh merged commit d4f5795 into main Dec 6, 2024
15 checks passed
@superlopuh superlopuh deleted the sasha/builtin/normalise-value branch December 6, 2024 00:47
EdmundGoodman pushed a commit to EdmundGoodman/xdsl that referenced this pull request Dec 6, 2024
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