-
Notifications
You must be signed in to change notification settings - Fork 26.3k
Resolve int[]? arguments to new OptionalIntArrayRef class
#70864
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
CI Flow Status⚛️ CI FlowRuleset - Version:
You can add a comment to the PR and tag @pytorchbot with the following commands: # ciflow rerun, "ciflow/default" will always be added automatically
@pytorchbot ciflow rerun
# ciflow rerun with additional labels "-l <ciflow/label_name>", which is equivalent to adding these labels manually and trigger the rerun
@pytorchbot ciflow rerun -l ciflow/scheduled -l ciflow/slowFor more information, please take a look at the CI Flow Wiki. |
🔗 Helpful links
💊 CI failures summary and remediationsAs of commit 005ad76 (more details on the Dr. CI page): 💚 💚 Looks good so far! There are no failures yet. 💚 💚 This comment was automatically generated by Dr. CI (expand for details).Please report bugs/suggestions to the (internal) Dr. CI Users group. |
int[]? dim arguments to new OptionalIntArrayRef class
tools/codegen/api/python.py
Outdated
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 OptionalArrayRef<T> makes sense for all types, not just int. e.g. a float[]? called with an int would likely have the exact same dangling pointer issue.
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.
That's true. Alright, I'll focus on fixing the remaining issues with int[]? --> OptionalIntArrayRef, and after that's fully working, I'll generalize for all OptionalArrayRef<T>
3ec8494 to
c4f5afd
Compare
aten/src/ATen/core/boxing/impl/make_boxed_from_unboxed_functor.h
Outdated
Show resolved
Hide resolved
aten/src/ATen/core/boxing/impl/make_boxed_from_unboxed_functor.h
Outdated
Show resolved
Hide resolved
ce8d647 to
6db2234
Compare
torch/backends/_nnapi/serializer.py
Outdated
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.
The changes I made to this file are kind of a hacky workaround. The upsample functions, not just upsample_nearest2d, have two different overloads that the parser checks for in the corresponding THPVariable_* function in torch/csrc/autograd/generated/python_nn_functions.cpp. For upsample_nearest2d, this used to be how the parser was defined before this PR:
static PythonArgParser parser({
"upsample_nearest2d(Tensor input, IntArrayRef? output_size, ArrayRef<double>? scale_factors)",
"upsample_nearest2d(Tensor input, IntArrayRef[2] output_size, double? scales_h=None, double? scales_w=None, *, Tensor out=None)",
}, /*traceable=*/true);If upsample_nearest2d is called with just the input and output_size, and no other arguments, both of the function schemas are a match, but the parser checks them in order, so the first one would be chosen. That worked fine until this PR changed IntArrayRef? to OptionalIntArrayRef. These entries are sorted in alphabetical order, so now they are switched:
static PythonArgParser parser({
"upsample_nearest2d(Tensor input, IntArrayRef[2] output_size, double? scales_h=None, double? scales_w=None, *, Tensor out=None)",
"upsample_nearest2d(Tensor input, OptionalIntArrayRef output_size, ArrayRef<double>? scale_factors)",
}, /*traceable=*/true); And now the wrong overload is chosen. The one with scales_h and scales_w is an old overload that still exists for BC, and it doesn't have all the features that the newer overload has.
One of the missing features was support for this NNAPI serializer. The change I made in this file adds support for that, and it seems to be working. It looks like upsample_nearest2d was the only upsample function that was supported here.
However, there's at least one more missing feature that won't be so simple (nor advisable, probably?) to add for these old overloads--forward AD. At the moment, all of the upsample functions are failing forward AD tests because of the overload reordering. If I could just change the order back to what it used to be, the issue should be fixed, but at the moment, I'm not completely sure how to do that. We could add specialized logic in codegen to reorder the upsample functions, but I'm not too sure if that's the best way to go or not. I haven't thought of any better idea though.
We could create THPVariable_ functions manually in tools/autograd/templates/python_nn_functions.cpp, but there are quite a few upsample functions affected by this:
THPVariable_upsample_bicubic2dTHPVariable_upsample_bilinear2dTHPVariable_upsample_linear1dTHPVariable_upsample_nearest1dTHPVariable_upsample_nearest2dTHPVariable_upsample_nearest3dTHPVariable_upsample_trilinear3d
@peterbell10 or @mruberry, do you have any thoughts?
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 just tried the codegen reordering idea, and it seems to work. I just reversed the grouped_overloads within the method_impl() function in tools/autograd/gen_python_functions.py any time it sees an upsample function:
| def method_impl( |
It looks like there already are some special-cased comparisons in the sorting function here:
| def sort_overloads( |
So I guess it might not be a bad idea to just add some logic there to prioritize OptionalIntArrayRef over IntArrayRef, or something like that.
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 all ambiguous overloads should behave equivalently; so I would consider this a bug in the nnapi code. The scales_h overload even looks to be the main overload in ATen, the other one just wraps it.
Also, while I just said it shouldn't matter. IntArrayRef is a more specific overload than OptionalIntArrayRef so it seems backwards to sort the Optional version first.
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.
That's a fair point. Then I guess we should enable forward AD for theIntArrayRef overloads?
Edit: I didn't realize how simple it is to add forward AD support for these--just needed to add result: auto_linear to each of them in derivatives.yaml. So I'll go ahead and push it
d4ef2fb to
ad61f38
Compare
int[]? dim arguments to new OptionalIntArrayRef classint[]? arguments to new OptionalIntArrayRef class
b96cc6e to
8f636f5
Compare
…ptional" We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
Pull Request resolved: #101995 We have C++17 now! I am intentionally dropping the c10::optional<c10::ArrayRef> size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use optional<ArrayRef> in function arguments anymore anyway. ghstack-source-id: 30231b8 Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/)
Pull Request resolved: #101995 We have C++17 now! I am intentionally dropping the c10::optional<c10::ArrayRef> size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use optional<ArrayRef> in function arguments anymore anyway. ghstack-source-id: 207227009 Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/)
…ptional" We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
…:optional to std::optional" We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
…::optional" We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
…ptional" We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
Pull Request resolved: #101995 We have C++17 now! I am intentionally dropping the c10::optional<c10::ArrayRef> size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use optional<ArrayRef> in function arguments anymore anyway. ghstack-source-id: 207417170 Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/)
…ptional" We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
Pull Request resolved: #101995 We have C++17 now! I am intentionally dropping the c10::optional<c10::ArrayRef> size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use optional<ArrayRef> in function arguments anymore anyway. ghstack-source-id: 207509669 Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/)
…ptional" We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
Pull Request resolved: #101995 We have C++17 now! I am intentionally dropping the c10::optional<c10::ArrayRef> size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use optional<ArrayRef> in function arguments anymore anyway. ghstack-source-id: 207558686 Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/)
…ptional" We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang [ghstack-poisoned]
…ptional" We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab mrshenli zhaojuanmao rohan-varma kiukchung d4l3k lucasllc XilunWu tianyu-l [ghstack-poisoned]
We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab mrshenli zhaojuanmao rohan-varma kiukchung d4l3k lucasllc XilunWu tianyu-l [ghstack-poisoned]
Pull Request resolved: #101995 We have C++17 now! I am intentionally dropping the c10::optional<c10::ArrayRef> size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use optional<ArrayRef> in function arguments anymore anyway. ghstack-source-id: 208581191 Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/)
Pull Request resolved: #101995 We have C++17 now! I am intentionally dropping the c10::optional<c10::ArrayRef> size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use optional<ArrayRef> in function arguments anymore anyway. ghstack-source-id: be773c9 Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/)
…ptional" We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab mrshenli zhaojuanmao rohan-varma kiukchung d4l3k lucasllc XilunWu tianyu-l [ghstack-poisoned]
We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) cc ezyang gchanan jgong5 mingfeima XiaobingSuper sanchitintel ashokei jingxu10 EikanWang H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab mrshenli zhaojuanmao rohan-varma kiukchung d4l3k lucasllc XilunWu tianyu-l [ghstack-poisoned]
We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) Pull Request resolved: #101995 Approved by: https://github.com/malfet, https://github.com/Skylion007, https://github.com/ezyang
We have C++17 now! I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / pytorch#70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway. Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/) Pull Request resolved: pytorch#101995 Approved by: https://github.com/malfet, https://github.com/Skylion007, https://github.com/ezyang
This PR uses the
OptionalArrayReftemplate class that was drafted in #64084.Fixes #44409