-
Notifications
You must be signed in to change notification settings - Fork 85
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) change data representation of DenseIntOrFPElements to use bytes #3623
Conversation
62a6866
to
8a721ad
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3623 +/- ##
==========================================
- Coverage 91.31% 91.31% -0.01%
==========================================
Files 468 468
Lines 58571 58578 +7
Branches 5652 5655 +3
==========================================
+ Hits 53485 53491 +6
- Misses 3634 3635 +1
Partials 1452 1452 ☔ View full report in Codecov by Sentry. |
Oh, I was completely unaware of the zero-rank tensor, sorry! I wrongfully assumed some of the tests were just a bit quirky. What still bothers me is the following test: xdsl/tests/dialects/test_builtin.py Line 220 in 8a721ad
this shouldn't be legal, right? storing two values in a zero-rank tensor? Does the following make sense as expected behaviour? # legal zero-rank tensor
attr = DenseIntOrFPElementsAttr.tensor_from_list([4], f32, [])
assert attr.type == AnyTensorType(f32, [])
# illegal zero-rank tensor
with pytest.raises(ValueError, match="A zero-rank tensor can only hold 1 value but 2 were given."):
DenseIntOrFPElementsAttr.tensor_from_list([4, 5], f32, [])
# legal normal tensor
attr = DenseIntOrFPElementsAttr.tensor_from_list([4, 5], f32, [2])
assert attr.type == AnyTensorType(f32, [2]) |
8a721ad
to
e061a16
Compare
e061a16
to
09e3bf0
Compare
xdsl/dialects/builtin.py
Outdated
if isinstance(self.type.element_type, AnyFloat): | ||
return tuple( | ||
FloatAttr(value, self.type.element_type) | ||
for value in cast(tuple[float, ...], self.get_values()) | ||
) | ||
elif isinstance(self.type.element_type, IntegerType): | ||
return tuple( | ||
IntegerAttr(value, self.type.element_type) | ||
for value in cast(tuple[int, ...], self.get_values()) | ||
) | ||
else: # index | ||
return tuple( | ||
IntegerAttr(value, self.type.element_type) | ||
for value in cast(tuple[int, ...], self.get_values()) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be a great helper in a separate PR, I think, and also provided for DenseArrayBase. I wonder if we should change iter/unpack
to iter_values/unpack_values
and iter_attrs/unpack_attrs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for the sake of ideal PRs, it would be great to split out all the changes that aren't in builtin.py to a separate PR, so that the underlying storage change is transparent, if that's not too tedious! |
e8d321f
to
603b0f1
Compare
This is now rebased, only remaining with changes in the class definition itself! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀🚀
No description provided.