Skip to content
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

Make numel equal test size oblivious in reshape_symint #124611

Closed
wants to merge 2 commits into from

Conversation

ezyang
Copy link
Contributor

@ezyang ezyang commented Apr 22, 2024

Stack from ghstack (oldest at bottom):

Fixes #124581

Signed-off-by: Edward Z. Yang ezyang@meta.com

[ghstack-poisoned]
Copy link

pytorch-bot bot commented Apr 22, 2024

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/124611

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

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

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

ezyang added a commit that referenced this pull request Apr 22, 2024
Fixes #124581

Signed-off-by: Edward Z. Yang <ezyang@meta.com>

ghstack-source-id: 71b944cef5d0099561437e781710d31f054471ec
Pull Request resolved: #124611
@@ -37,7 +37,7 @@ inline void infer_size_impl(
}
}

if (numel == newsize || (infer_dim && newsize > 0 && numel % newsize == 0)) {
if (TORCH_GUARD_SIZE_OBLIVIOUS(sym_eq(numel, newsize)) || (infer_dim && newsize > 0 && numel % newsize == 0)) {
Copy link
Contributor

@bdhirsh bdhirsh Apr 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, one question about size-oblivious guards:

So far I've thought their main use case as being for when we have some pytorch code that diverges on two cases (one for the 0/1 case and one for the general case), and we've decided that the general case is safe to use all the time when our size variable is unbacked. The example in my head being that squeeze() will repeatedly remove consecutive dims of size 1, which we will ignore when our dims are unbacked.

Here though, every single size check in this function is effectively an error check (if the sizes don't match then our reshape should error).

So size oblivious guards don't seem wrong here (the "correct" path is probably not to error). But do you think that TORCH_SYM_CHECK is more the right tool for this case (which basically says "always take the non-erroring path, but add runtime asserts for it)? Or maybe I'm holding this wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right that a deferred runtime assert might be even better. But it's nontrivial to convert this into a torch._check because of the disjunction. It may be possible, I just went for the simplest thing in this PR.

@albanD albanD removed their request for review April 22, 2024 14:21
[ghstack-poisoned]
ezyang added a commit that referenced this pull request Apr 22, 2024
Fixes #124581

Signed-off-by: Edward Z. Yang <ezyang@meta.com>

ghstack-source-id: 28c893a6a74a3c4cb59188522bfadd4b5ce8466d
Pull Request resolved: #124611
@ezyang
Copy link
Contributor Author

ezyang commented Apr 22, 2024

@pytorchbot merge -i

@pytorch-bot pytorch-bot bot added the ciflow/trunk Trigger trunk jobs on your pull request label Apr 22, 2024
@pytorchmergebot
Copy link
Collaborator

Merge failed

Reason: This PR needs a release notes: label
If your changes are user facing and intended to be a part of release notes, please use a label starting with release notes:.

If not, please add the topic: not user facing label.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "topic: not user facing"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

Details for Dev Infra team Raised by workflow job

@ezyang ezyang added the topic: not user facing topic category label Apr 22, 2024
@ezyang
Copy link
Contributor Author

ezyang commented Apr 22, 2024

@pytorchbot merge

@pytorchmergebot
Copy link
Collaborator

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging
Check the merge workflow status
here

carmocca pushed a commit to carmocca/pytorch that referenced this pull request Apr 29, 2024
Fixes pytorch#124581

Signed-off-by: Edward Z. Yang <ezyang@meta.com>
Pull Request resolved: pytorch#124611
Approved by: https://github.com/bdhirsh
ghstack dependencies: pytorch#124139
andoorve pushed a commit to andoorve/pytorch that referenced this pull request May 1, 2024
Fixes pytorch#124581

Signed-off-by: Edward Z. Yang <ezyang@meta.com>
Pull Request resolved: pytorch#124611
Approved by: https://github.com/bdhirsh
ghstack dependencies: pytorch#124139
petrex pushed a commit to petrex/pytorch that referenced this pull request May 3, 2024
Fixes pytorch#124581

Signed-off-by: Edward Z. Yang <ezyang@meta.com>
Pull Request resolved: pytorch#124611
Approved by: https://github.com/bdhirsh
ghstack dependencies: pytorch#124139
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci-td-distributed ciflow/trunk Trigger trunk jobs on your pull request Merged topic: not user facing topic category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants