-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
[WIP][Pytorch] add operator copy_ support #6049
Conversation
@masahi would you please take a look? |
@huajsj please add a test. Also, |
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.
In addition to the missing test.
- Could you explain your use case a bit? In particular, what PyTorch constructs map to
copy_
in the graph and for which version. - One internal use of
copy_
in PyTorch is as the implementation of.to
and related shortcuts, but at least recent versions of PyTorch seem to export the proper commands for.to
,.double
and.cuda
(with.double
mapping to some less-than-official_cast_Double
op). - The other main use of
copy_
I'm aware of is for assigning tensors to slices and other views (i.e.t[:1] = s
but alsot.diag().copy_(foo)
to set the diagonal), but clone would not help here. I'm not sure that TVM will handle view semantics. - I don't think mapping to
clone
captures the semantics ofcopy_(a, b)
even in absence of views: After copying, thea
has the values ofb
but keeps device and dtype ofa
and it also returnsa
.
I don't think we have the analysis to support inplace properly (and note that PyTorch has some un-implacing pass for the easy cases, but I don't know if we can use it / are using it).
@masahi I don't there is a copy
(it's clone()
) and it would not help in the cases above.
Thanks for the review, following are my comments Regards #1 about use case and why copy_ , from my understanding copy_ is not only a shortcut of .to, the biggest difference between copy_ and .clone , .to is that the in place variable would keep it's stride&storage and size, for example for following use case, .clone and .to would cause b lost it's stride/storage information, running environment is pytorch 1.5. #2. about use case t.diag().copy_(a) , seems like currently pytorch front end not support diag operator, we may can not #3 about the copy operator, just like @t-vi mentioned, clone is the non in place one. #4. i agree with that clone is not capture the semantics of copy_ and find some problem during testing, would set this |
close this PR now, would create a new PR once find better solution. |
Issue:
Using tvm compile a pytorch network, tvm failed due to copy_ operator not support.
solution:
add pytorch copy_ operator support to tvm.