functionalization: add a copy() native function #76083
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[ghstack-poisoned]
🔗 Helpful links
💊 CI failures summary and remediationsAs of commit 34893d8 (more details on the Dr. CI page): Expand to see more
🕵️ 1 new failure recognized by patternsThe following CI failures do not appear to be due to upstream breakages
|
This was referenced Apr 20, 2022
[ghstack-poisoned]
Right now the functionalization codegen has special logic to handle `copy_()`. Instead, in this PR I add an `at::copy` native function (not exposed to python), and effectively move that logic into C++ and out of the codegen. `copy()` decomposes into `to` and `expand`, and it's CompositeImplicitAutograd so it won't appear in traces. One annoying thing - since `copy()` decomposes into a view op, and it decomposes "underneath" functionalization, I need to manually handle the case where we want to remove view ops from the functionalization pass. This feels not-too-awful mostly because `at::copy()` really just exists for the functionalization pass anyway. Existing tests for `copy_` in `test_functionalization.py` should test the change (since the end-result trace is the same). [ghstack-poisoned]
This was referenced Apr 20, 2022
ezyang
approved these changes
Apr 21, 2022
Right now the functionalization codegen has special logic to handle `copy_()`. Instead, in this PR I add an `at::copy` native function (not exposed to python), and effectively move that logic into C++ and out of the codegen. `copy()` decomposes into `to` and `expand`, and it's CompositeImplicitAutograd so it won't appear in traces. One annoying thing - since `copy()` decomposes into a view op, and it decomposes "underneath" functionalization, I need to manually handle the case where we want to remove view ops from the functionalization pass. This feels not-too-awful mostly because `at::copy()` really just exists for the functionalization pass anyway. Existing tests for `copy_` in `test_functionalization.py` should test the change (since the end-result trace is the same). [ghstack-poisoned]
This was referenced Apr 21, 2022
Right now the functionalization codegen has special logic to handle `copy_()`. Instead, in this PR I add an `at::copy` native function (not exposed to python), and effectively move that logic into C++ and out of the codegen. `copy()` decomposes into `to` and `expand`, and it's CompositeImplicitAutograd so it won't appear in traces. One annoying thing - since `copy()` decomposes into a view op, and it decomposes "underneath" functionalization, I need to manually handle the case where we want to remove view ops from the functionalization pass. This feels not-too-awful mostly because `at::copy()` really just exists for the functionalization pass anyway. Existing tests for `copy_` in `test_functionalization.py` should test the change (since the end-result trace is the same). [ghstack-poisoned]
Right now the functionalization codegen has special logic to handle `copy_()`. Instead, in this PR I add an `at::copy` native function (not exposed to python), and effectively move that logic into C++ and out of the codegen. `copy()` decomposes into `to` and `expand`, and it's CompositeImplicitAutograd so it won't appear in traces. One annoying thing - since `copy()` decomposes into a view op, and it decomposes "underneath" functionalization, I need to manually handle the case where we want to remove view ops from the functionalization pass. This feels not-too-awful mostly because `at::copy()` really just exists for the functionalization pass anyway. Existing tests for `copy_` in `test_functionalization.py` should test the change (since the end-result trace is the same). [ghstack-poisoned]
Right now the functionalization codegen has special logic to handle `copy_()`. Instead, in this PR I add an `at::copy` native function (not exposed to python), and effectively move that logic into C++ and out of the codegen. `copy()` decomposes into `to` and `expand`, and it's CompositeImplicitAutograd so it won't appear in traces. One annoying thing - since `copy()` decomposes into a view op, and it decomposes "underneath" functionalization, I need to manually handle the case where we want to remove view ops from the functionalization pass. This feels not-too-awful mostly because `at::copy()` really just exists for the functionalization pass anyway. Existing tests for `copy_` in `test_functionalization.py` should test the change (since the end-result trace is the same). [ghstack-poisoned]
Right now the functionalization codegen has special logic to handle `copy_()`. Instead, in this PR I add an `at::copy` native function (not exposed to python), and effectively move that logic into C++ and out of the codegen. `copy()` decomposes into `to` and `expand`, and it's CompositeImplicitAutograd so it won't appear in traces. One annoying thing - since `copy()` decomposes into a view op, and it decomposes "underneath" functionalization, I need to manually handle the case where we want to remove view ops from the functionalization pass. This feels not-too-awful mostly because `at::copy()` really just exists for the functionalization pass anyway. Existing tests for `copy_` in `test_functionalization.py` should test the change (since the end-result trace is the same). [ghstack-poisoned]
This was referenced Apr 25, 2022
Right now the functionalization codegen has special logic to handle `copy_()`. Instead, in this PR I add an `at::copy` native function (not exposed to python), and effectively move that logic into C++ and out of the codegen. `copy()` decomposes into `to` and `expand`, and it's CompositeImplicitAutograd so it won't appear in traces. One annoying thing - since `copy()` decomposes into a view op, and it decomposes "underneath" functionalization, I need to manually handle the case where we want to remove view ops from the functionalization pass. This feels not-too-awful mostly because `at::copy()` really just exists for the functionalization pass anyway. Existing tests for `copy_` in `test_functionalization.py` should test the change (since the end-result trace is the same). [ghstack-poisoned]
|
@pytorchbot merge this please |
|
Hey @bdhirsh. |
facebook-github-bot
pushed a commit
that referenced
this pull request
Apr 26, 2022
Summary: Pull Request resolved: #76083 Approved by: https://github.com/albanD Test Plan: contbuild & OSS CI, see https://hud.pytorch.org/commit/pytorch/pytorch/5da76acd1d8ad1c40f8d58d52a12aa215dbae7ce Reviewed By: osalpekar Differential Revision: D35938186 Pulled By: bdhirsh fbshipit-source-id: 4a93d39088b5944cf4911c9c08feb549ecb72ac3
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Right now the functionalization codegen has special logic to handle
copy_(). Instead, in this PR I add anat::copynative function (not exposed to python), and effectively move that logic into C++ and out of the codegen.copy()decomposes intotoandexpand, and it's CompositeImplicitAutograd so it won't appear in traces.One annoying thing - since
copy()decomposes into a view op, and it decomposes "underneath" functionalization, I need to manually handle the case where we want to remove view ops from the functionalization pass. This feels not-too-awful mostly becauseat::copy()really just exists for the functionalization pass anyway.Existing tests for
copy_intest_functionalization.pyshould test the change (since the end-result trace is the same).Stack from ghstack: