-
Notifications
You must be signed in to change notification settings - Fork 72
[pass] Fix DCE to keep initializers that are inputs #2245
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
Conversation
Add check initializer for input remains
keeping input initializers
Update unused_removal.py
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.
Thanks!
Co-authored-by: Justin Chu <[email protected]>
❌ 1 Tests Failed:
View the top 1 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
warn user about unused initialized inputs
moved removing unused inputs to special function
for i, inp in reversed(list(enumerate(graph_inputs))): | ||
if inp.name in initializers and not (inp.uses() or inp in graph_outputs): | ||
if self.remove_initialized_inputs: | ||
del graph_inputs[i] |
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.
Why would a user want to remove a graph-input? It is part of its signature. Even if the input is never used. It could potentially fail in a system when the user specifies an input-value, and the system rejects it as an invalid input (eg., could happen with onnxruntime). Against this disadvantage, there is nothing much gained by removing the model input.
The initializer value can, however, be removed, if there is no use of that value within the model. May be that will save some memory for large initializers.
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 the scenario is that when an initializer happens to be declared an input (as it can be in some converters), if only the initializer is removed but not the input, the same calling will fail. A user may decide to not care about those inputs since for example in ort inputs are provided by keyword.
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.
Why would a user want to remove a graph-input?
...
The issue arose from concrete real life net I need to process, see
#2211
That's the result of transforming a net, which every weight was declared initialized input. I'm not sure, what exactly creator meant, may be probing.
...
The initializer value can, however, be removed, ...
Nope. I have provided the example here:
#2235 (comment)
func name
Moved outsede the class
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.
@leshabirukov Apologize but after discussion with @gramalingam , we think that instead of creating an option, it is better to separately handle the initialized inputs. I am working on this in #2253. If you may, could you retain the line if not (init.uses() or init in graph_outputs or init in graph_inputs):
, and remove the rest of the changes in the PR? I will update this other PR to provide the needed functionality
@leshabirukov I have created #2257. Unfortunately we will have to revert some of the changes you made in favor of #2253. Will the proposed passes work for you? |
No problem, once I was aware of dangling initialized input issue, I new what to do with that. But think about people hit the same issue, I insist, there should be the warning at least. I propose to preserve this function, (in another file if it should):
And call it from DCE with |
Thanks. I think that’s reasonable |
ok, then two questions:
|
Sure!
|
ok, don't forget about warning for DCE |
Fix #2235