-
Notifications
You must be signed in to change notification settings - Fork 6
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
i32 index fixes #180
base: mlir
Are you sure you want to change the base?
i32 index fixes #180
Conversation
SmallVector<int64_t> order(coords.begin(), coords.end()); | ||
SmallVector<int64_t> order; | ||
if (ov_order_element_type == ov::element::i64) { | ||
ov::Coordinate coords = const_order->get_coordinate_val(); |
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.
Indices in const_order
as the second input of Transpose
cannot be negative, so you can just use const_order->cast_vector<uint64_t>()
and leave negative indices as UB.
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.
Right, I tried that, but got only partial result for some reason. Half of the values were correct, others - zeroes.
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.
Make sure that you used cast_vector
, not get_vector
.
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.
Ah, I see
These are what I have found while experimenting with different small models. When the type of an index is i32 it doesn't fit into an mlir op and there might be problems with accessing them through the constant op on OV side (I'd seen partial data for example). There are quick fixes for the issues I've seen so far.