Skip to content

[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

Closed
wants to merge 3 commits into from

Conversation

jorgep31415
Copy link
Contributor

@jorgep31415 jorgep31415 commented Apr 3, 2024

Stack from ghstack (oldest at bottom):

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

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]
Copy link

pytorch-bot bot commented Apr 3, 2024

🔗 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 Failures

As of commit a936581 with merge base d3326a2 (image):
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Apr 3, 2024
@facebook-github-bot
Copy link
Contributor

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]
@facebook-github-bot
Copy link
Contributor

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]
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D55703483

@facebook-github-bot
Copy link
Contributor

This pull request has been merged in 9630f9d.

@mergennachin mergennachin mentioned this pull request Apr 26, 2024
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/)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported Merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants