-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Fix coverity issues #30082
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
base: master
Are you sure you want to change the base?
Fix coverity issues #30082
Conversation
src/common/low_precision_transformations/src/pull_reshape_through_dequantization.cpp
Outdated
Show resolved
Hide resolved
…ugh_dequantization.cpp Co-authored-by: Andrii Staikov <andrii.staikov@intel.com>
auto child = reshape_target_inputs.begin()->get_node(); | ||
if (ov::is_type<opset1::GroupConvolution>(child)) { | ||
return false; | ||
} |
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.
Is there any reason why this is not a part of the pattern?
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.
not so sure, but probably because we check that GroupConvolution is the first child ( .begin()
)
if we add this subgraph "reshape -> group_conv" to the pattern, we will have to check that group_conv
is the first child anyway
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.
Actually if any of the consumers is GroupConvolution
, we shouldn't perform this transformation.
Such dequantization subgraphs can be shared between several nodes with the same type in some rare cases (however, I haven't seen such cases with GroupConvolution), so we could stop this transformation when all the consumers are GroupConvs. But theoretically there may be some ShapeOf subgraphs starting from this reshape, so maybe "all_of" check is too strict
Details:
Fixed "dereference before null check" issues
Tickets: