-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
[ONNX] Reduce* refactoring #23429
[ONNX] Reduce* refactoring #23429
Conversation
f860fae
to
a60c525
Compare
const std::set<element::Type> supported_types_v1 = | ||
{element::u32, element::u64, element::i32, element::i64, element::f16, element::f32, element::f64}; | ||
const std::set<element::Type> supported_types_v2 = | ||
{element::u32, element::u64, element::i32, element::i64, element::f16, element::f32, element::f64, element::bf16}; |
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.
I think we do need to check input types to Reduce
operation. That is because we assume input model is originally consistent (it comes with correct input type) and our Reduce
operation should work for all of this operations
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 way we can explore limitation in core part and request to extend on new types if needed.
Let us say if some type not supported by core (or plugin, etc.) is needed by some model, then we should insert Convert operation that is not good.
We should rather to avoid any limitations in our part, assume that input model is consistent, and encourage other components avoid limitations.
### Details: - Refactored source code to be able co-work with others - Removed unnecessary comments - Added check for a wrong input type - Added tests for an exception for wrong input type ### Tickets: - 125493
Details:
Tickets: