[ET-VK] Introduce add_tensor overloads consuming TensorRef#2835
Closed
junpi3 wants to merge 3 commits intogh/jorgep31415/40/basefrom
Closed
[ET-VK] Introduce add_tensor overloads consuming TensorRef#2835junpi3 wants to merge 3 commits intogh/jorgep31415/40/basefrom
junpi3 wants to merge 3 commits intogh/jorgep31415/40/basefrom
Conversation
From @SSJia: > we should always make sure to store references produced from `graph.get_val()` only after any calls to `graph.add_*()` (i.e. modifications to the values list) are made. This is because `graph.values_`, being a `std::vector`, will reallocate with more space and move its contents if the current allocation is not sufficient. This means that if you store a reference then call `graph.add_*()` then the underlying resource the reference points to may have been moved. I think we can guard against this behavior by passing a `TensorRef` directly, and never having to declare a variable `TensorRef& tref` in the caller's scope. An example is shown in `Staging.cpp`. We could have it consume `ValueRef` for brevity of the passing parameter but IMO it hinders readability. Differential Revision: [D55703483](https://our.internmc.facebook.com/intern/diff/D55703483/) [ghstack-poisoned]
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/2835
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit a936581 with merge base d3326a2 ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
facebook-github-bot
added
the
CLA Signed
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D55703483 |
This was referenced Apr 3, 2024
SS-JIA
approved these changes
Apr 3, 2024
From ssjia: > we should always make sure to store references produced from `graph.get_val()` only after any calls to `graph.add_*()` (i.e. modifications to the values list) are made. This is because `graph.values_`, being a `std::vector`, will reallocate with more space and move its contents if the current allocation is not sufficient. This means that if you store a reference then call `graph.add_*()` then the underlying resource the reference points to may have been moved. I think we can guard against this behavior by passing a `TensorRef` directly, and never having to declare a variable `TensorRef& tref` in the caller's scope. An example is shown in `Staging.cpp`. We could have it consume `ValueRef` for brevity of the passing parameter but IMO it hinders readability. Differential Revision: [D55703483](https://our.internmc.facebook.com/intern/diff/D55703483/) [ghstack-poisoned]
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D55703483 |
This was referenced Apr 4, 2024
Closed
From ssjia: > we should always make sure to store references produced from `graph.get_val()` only after any calls to `graph.add_*()` (i.e. modifications to the values list) are made. This is because `graph.values_`, being a `std::vector`, will reallocate with more space and move its contents if the current allocation is not sufficient. This means that if you store a reference then call `graph.add_*()` then the underlying resource the reference points to may have been moved. I think we can guard against this behavior by passing a `TensorRef` directly, and never having to declare a variable `TensorRef& tref` in the caller's scope. An example is shown in `Staging.cpp`. We could have it consume `ValueRef` for brevity of the passing parameter but IMO it hinders readability. Differential Revision: [D55703483](https://our.internmc.facebook.com/intern/diff/D55703483/) [ghstack-poisoned]
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D55703483 |
Contributor
|
This pull request has been merged in 9630f9d. |
Closed
kedarnath03
pushed a commit
to kedarnath03/executorch
that referenced
this pull request
Jun 25, 2025
Pull Request resolved: pytorch/executorch#2835 From @SSJia: > we should always make sure to store references produced from `graph.get_val()` only after any calls to `graph.add_*()` (i.e. modifications to the values list) are made. This is because `graph.values_`, being a `std::vector`, will reallocate with more space and move its contents if the current allocation is not sufficient. This means that if you store a reference then call `graph.add_*()` then the underlying resource the reference points to may have been moved. We can guard against this behavior by passing a `ValueRef` directly, and never having to declare a variable of types `ValueRef&/TensorRef&` in the caller's scope. An example is shown in `Staging.cpp`. ghstack-source-id: 221721758 @exported-using-ghexport Differential Revision: [D55703483](https://our.internmc.facebook.com/intern/diff/D55703483/)
kedarnath03
pushed a commit
to kedarnath03/executorch
that referenced
this pull request
Jun 25, 2025
Pull Request resolved: pytorch/executorch#2835 From @SSJia: > we should always make sure to store references produced from `graph.get_val()` only after any calls to `graph.add_*()` (i.e. modifications to the values list) are made. This is because `graph.values_`, being a `std::vector`, will reallocate with more space and move its contents if the current allocation is not sufficient. This means that if you store a reference then call `graph.add_*()` then the underlying resource the reference points to may have been moved. We can guard against this behavior by passing a `ValueRef` directly, and never having to declare a variable of types `ValueRef&/TensorRef&` in the caller's scope. An example is shown in `Staging.cpp`. ghstack-source-id: 221175880 @exported-using-ghexport Differential Revision: [D55703483](https://our.internmc.facebook.com/intern/diff/D55703483/)
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Stack from ghstack (oldest at bottom):
From @SSJia:
I think we can guard against this behavior by passing a
TensorRefdirectly, and never having to declare a variableTensorRef& trefin the caller's scope. An example is shown inStaging.cpp. We could have it consumeValueReffor brevity of the passing parameter but IMO it hinders readability.Differential Revision: D55703483