-
Notifications
You must be signed in to change notification settings - Fork 26.3k
Add CallMethod, inline eagerly #21116
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
Summary: This adds CallMethod to complement CallFunction. Now class method calls are first emitted using CallMethod and Inline then removes them. This preserves intent in the IR better and will be how Interfaces (actually dynamically dispatched methods) will appear in the IR Test Plan: test_jit.py
Add CallMethod, inline eagerly Summary: This adds CallMethod to complement CallFunction. Now class method calls are first emitted using CallMethod and Inline then removes them. This preserves intent in the IR better and will be how Interfaces (actually dynamically dispatched methods) will appear in the IR Test Plan: test_jit.py gh-metadata: pytorch pytorch 21116 gh/zdevito/42/head
Add CallMethod, inline eagerly Summary: This adds CallMethod to complement CallFunction. Now class method calls are first emitted using CallMethod and Inline then removes them. This preserves intent in the IR better and will be how Interfaces (actually dynamically dispatched methods) will appear in the IR Test Plan: test_jit.py gh-metadata: pytorch pytorch 21116 gh/zdevito/42/head
Add CallMethod, inline eagerly Summary: This adds CallMethod to complement CallFunction. Now class method calls are first emitted using CallMethod and Inline then removes them. This preserves intent in the IR better and will be how Interfaces (actually dynamically dispatched methods) will appear in the IR Test Plan: test_jit.py gh-metadata: pytorch pytorch 21116 gh/zdevito/42/head
| loc, f, inputsWithSelf, attributes, n_binders); | ||
| auto method = self_->type()->expect<ClassType>()->getMethod(method_name_); | ||
| TORCH_INTERNAL_ASSERT(method); | ||
| method->ensure_defined(); |
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.
It seems we are frequently calling ensure_defined() before doing something with a method—I think lazy compilation should be an internal detail of Method and callers shouldn't need to know about it. Don't have to change it here though.
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 with this, but I don't know of a great place to put it yet. It is possible that we can choose which methods on Function should just call it but I haven't figured out if that works.
|
|
||
| TORCH_API const std::vector<Function*>& getAllBuiltinFunctionsFor(Symbol name); | ||
|
|
||
| TORCH_API const std::vector<std::shared_ptr<Function>>& |
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 did we change these to owning pointers?
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.
Because the FunctionType object captures them as such when an emitCall happens.
Stack from ghstack:
Summary: This adds CallMethod to complement CallFunction. Now class
method calls are first emitted using CallMethod and Inline then removes
them. This preserves intent in the IR better and will be how Interfaces
(actually dynamically dispatched methods) will appear in the IR
Test Plan: test_jit.py
Differential Revision: D15552816