-
Notifications
You must be signed in to change notification settings - Fork 25.1k
Fix inlining interface call in fork subgraph #43790
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
Interface calls were not handled properly when they are used in fork subgraph. This PR fixes this issue. [ghstack-poisoned]
💊 CI failures summary and remediationsAs of commit 63269ea (more details on the Dr. CI page):
🕵️ 1 new failure recognized by patternsThe following CI failures do not appear to be due to upstream breakages:
|
Interface calls were not handled properly when they are used in fork subgraph. This PR fixes this issue. Differential Revision: [D23402039](https://our.internmc.facebook.com/intern/diff/D23402039) [ghstack-poisoned]
@@ -479,6 +482,9 @@ class AttributePropagator { | |||
if (node->kind() != prim::GetAttr) { | |||
return; | |||
} | |||
if (!node->output()->type()->cast<ClassType>()) { |
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 are we doing this check ? Could you add a comment into the code ?
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.
One of my unit test fired because I call a global method? I don't anticipate this to happen in practice.
I feel this is still fragile because we expect the first argument of fork to be submodule of the invoked method which is just a convention.
Anyway freezing will fail if it tries to resolve an attribute that does not exist. I guess it is okay in case someone wants to get creative and pass the submodule as second argument ...
I will add a comment
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 should still be recursively analyzing the fork even if it's not a forked module - don't we still want to inline interface calls and such ?
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 agree. I updated my PR to handle in this case
Interface calls were not handled properly when they are used in fork subgraph. This PR fixes this issue. Differential Revision: [D23402039](https://our.internmc.facebook.com/intern/diff/D23402039) [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.
LGTM
Interface calls were not handled properly when they are used in fork subgraph. This PR fixes this issue. Differential Revision: [D23402039](https://our.internmc.facebook.com/intern/diff/D23402039) [ghstack-poisoned]
Stack from ghstack:
Interface calls were not handled properly when they are used in fork
subgraph. This PR fixes this issue.
Differential Revision: D23402039