fix schema matching of tuples to vartype lists#25944
fix schema matching of tuples to vartype lists#25944eellison wants to merge 7 commits intopytorch:masterfrom
Conversation
|
I would prefer if @zdevito reviewed this as he was working on changing schema matching stuff recently |
|
@suo most of the PR is just test / mechanical changes |
|
@pytorchbot rebase this please |
There was a problem hiding this comment.
https://github.com/pytorch/pytorch/blob/master/torch/csrc/utils/python_arg_parser.cpp#L490
Specifies that this functionality is only supposed to work for intlists, but looking at test failures it looks like this is also being used for broadcast_tensors
|
We hit a particularly nasty bug in the same codepath that is going to take a week of work to sort out, so I do want to carefully review this. Any change to type promotion rules should always have high scrutiny. |
zdevito
left a comment
There was a problem hiding this comment.
This looks correct. A couple cleanups:
- Test if the allow_conversions flag is really required, I think it will get caught by the isSubtypeOf checks that happen after matching anyway and it bloats the footprint of this change substantially.
- Potentially move the tests to python if possible.
aten/src/ATen/core/type.cpp
Outdated
There was a problem hiding this comment.
A for loop would be a lot cleaner here. It would remove the weird nullptr propagation logic, and allow for the short circute and return of nullptr.
aten/src/ATen/core/type.cpp
Outdated
There was a problem hiding this comment.
Why does this return optional but unifyTypes return TypePtr that might be null. This should be consistent with TypePtr.
There was a problem hiding this comment.
unifyTypes returns an optional
aten/src/ATen/core/jit_type.h
Outdated
There was a problem hiding this comment.
I don't think we need this bool because we still check subtyping relationships after matching type variables. Even if we always allow potential matches, it will still have the same behavior.
There was a problem hiding this comment.
use the testing namespace. Otherwise someone can write torch.test_vartype in the C++ frontend and it will work.
There was a problem hiding this comment.
Will use the testing namespace - however this op only gets defined when the test is run right ? i don't think torch.test_vartype would be defined
There was a problem hiding this comment.
as it is written, yes it will only appear here.
There was a problem hiding this comment.
Can we avoid using low-level APIs like this in tests, it adds work to any refactoring. Please use Module and its define methods and ways of running methods.
There was a problem hiding this comment.
actually, why are these C++ tests at all? If this is just running code but using a custom op, then just define the testing op in register_builtin_ops and write python tests.
There was a problem hiding this comment.
I wrote the tests in c++ so that the op only gets defined when the tests are run and we don't have unnecessary ops in in the runtime.
There was a problem hiding this comment.
It is not specific to intlist, the comment is wrong.
eellison
left a comment
There was a problem hiding this comment.
Good point about not needing the allow_conversions arg. Re: c++. I would rather not mix together test ops and real ones. previously I used c++ for test ops
pytorch/test/cpp/jit/test_misc.cpp
Line 907 in efc5306
aten/src/ATen/core/type.cpp
Outdated
There was a problem hiding this comment.
unifyTypes returns an optional
There was a problem hiding this comment.
I wrote the tests in c++ so that the op only gets defined when the tests are run and we don't have unnecessary ops in in the runtime.
There was a problem hiding this comment.
Will use the testing namespace - however this op only gets defined when the test is run right ? i don't think torch.test_vartype would be defined
8597000 to
b3aa3af
Compare
facebook-github-bot
left a comment
There was a problem hiding this comment.
@eellison is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
Summary: In schema matching we allow a homogenous tuple to be matched to list arguments. This logic wasn't yet extended for vartype lists, causing stuff like `len((1, 2, 3))` to fail. Fix for pytorch/pytorch#20500 Pull Request resolved: pytorch/pytorch#25944 Differential Revision: D17431514 Pulled By: eellison fbshipit-source-id: 2ad98bab15eaa496471df651572735eb35183323
facebook-github-bot
left a comment
There was a problem hiding this comment.
@eellison has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
|
@pytorchbot rebase this please |
facebook-github-bot
left a comment
There was a problem hiding this comment.
@eellison has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
Summary: In schema matching we allow a homogenous tuple to be matched to list arguments. This logic wasn't yet extended for vartype lists, causing stuff like `len((1, 2, 3))` to fail. Fix for pytorch/pytorch#20500 Pull Request resolved: pytorch/pytorch#25944 Differential Revision: D17482510 Pulled By: eellison fbshipit-source-id: aa63318c27a01d965a7a7b68ce8bec638168dc26
In schema matching we allow a homogenous tuple to be matched to list arguments. This logic wasn't yet extended for vartype lists, causing stuff like
len((1, 2, 3))to fail.Fix for #20500