-
Notifications
You must be signed in to change notification settings - Fork 25.6k
[JIT] check for object equality in constant pooling #31800
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
[ghstack-poisoned]
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.
Looks good to me
💊 CircleCI build failures summary and remediationsAs of commit da840cd: None of the build failures appear to be your fault.
Detailed failure analysisOne may explore the probable reasons each build failed interactively on the Dr. CI website. 🚧 1 upstream failure recognized by patterns:These builds matched patterns, but were probably caused by upstream breakages:
This comment was automatically generated by Dr. CI (expand for details).Follow this link to opt-out of these comments for your Pull Requests.Please report bugs/suggestions on the GitHub issue tracker. This comment has been revised 17 times. |
|
||
// if both values are the same object, we do not need to worry about | ||
// changing the aliasing relationship | ||
bool same_idenity = |
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.
s/same_idenity/same_identity/
If we know that two constants are the same object, we can ignore other constraints and pool them together. This fixes an issue introduced by the other PR where quantization relied on constant pooling happening for correctness. Differential Revision: [D19269499](https://our.internmc.facebook.com/intern/diff/D19269499) [ghstack-poisoned]
|
||
c10::optional<IValue> toIValue(const Value* v) { | ||
if (v->node()->kind() != prim::Constant) { | ||
if (v->node()->kind() != prim::Constant || v->type()->cast<FunctionType>()) { |
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 constant Function nodes?
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.
Yea
If we know that two constants are the same object, we can ignore other constraints and pool them together. This fixes an issue introduced by the other PR where quantization relied on constant pooling happening for correctness. Differential Revision: [D19269499](https://our.internmc.facebook.com/intern/diff/D19269499) [ghstack-poisoned]
If we know that two constants are the same object, we can ignore other constraints and pool them together. This fixes an issue introduced by the other PR where quantization relied on constant pooling happening for correctness. Differential Revision: [D19269499](https://our.internmc.facebook.com/intern/diff/D19269499) [ghstack-poisoned]
Summary: Pull Request resolved: pytorch#31800 If we know that two constants are the same object, we can ignore other constraints and pool them together. This fixes an issue introduced by the other PR where quantization relied on constant pooling happening for correctness. Test Plan: Imported from OSS Differential Revision: D19269499 Pulled By: eellison fbshipit-source-id: 9d4396125aa6899cb081863d463d4f024135cbf4
Stack from ghstack:
If we know that two constants are the same object, we can ignore other constraints and pool them together. This fixes an issue introduced by the other PR where quantization relied on constant pooling happening for correctness.
Differential Revision: D19269499