-
Notifications
You must be signed in to change notification settings - Fork 607
[ET-VK] Introduce add_tensor overloads consuming TensorRef #2835
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
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. |
This pull request was exported from Phabricator. Differential Revision: D55703483 |
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]
This pull request was exported from Phabricator. Differential Revision: D55703483 |
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]
This pull request was exported from Phabricator. Differential Revision: D55703483 |
This pull request has been merged in 9630f9d. |
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/)
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/)
Stack from ghstack (oldest at bottom):
From @SSJia:
I think we can guard against this behavior by passing a
TensorRef
directly, and never having to declare a variableTensorRef& tref
in the caller's scope. An example is shown inStaging.cpp
. We could have it consumeValueRef
for brevity of the passing parameter but IMO it hinders readability.Differential Revision: D55703483