Skip to content

symintify all of derivatives.yaml#86610

Closed
bdhirsh wants to merge 15 commits intogh/bdhirsh/324/basefrom
gh/bdhirsh/324/head
Closed

symintify all of derivatives.yaml#86610
bdhirsh wants to merge 15 commits intogh/bdhirsh/324/basefrom
gh/bdhirsh/324/head

Conversation

@bdhirsh
Copy link
Collaborator

@bdhirsh bdhirsh commented Oct 10, 2022

Big-bang PR to symintify all .sizes() calls in derivatives.yaml, which will be needed for symbolic tracing.

  • with the exception of split(), which is tougher to land because it requires internal changes.

Stack from ghstack (oldest at bottom):

@pytorch-bot
Copy link

pytorch-bot bot commented Oct 10, 2022

🔗 Helpful Links

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

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

✅ No Failures

As of commit bfc235d:
💚 Looks good so far! There are no failures yet. 💚

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

// The below ops don't get a duplicated C++ implementation.
// They are backward ops, which make them very unlikely to be called directly
// by external code (at::native::trace_backward).
// They get their own declaration for BC purposes however.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@albanD @wconstab wondering if anyone has thoughts on this. Keeping these extra ops for BC to guarantee no internal failures felt like a good idea. But instead of duplicating all of the code, I just routed them to the symint variants (cuts down on code size a bunch but is marginally slower - shouldn't really matter in practice though, since hopefully nobody is calling these).

#include <c10/core/QScheme.h>
#include <ATen/core/Reduction.h>
#include <ATen/core/Tensor.h>
#include <ATen/native/NonSymbolicBC.h>
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The other change to minimize (guarantee?) no internal breakages is here - fbcode uses NativeFunctions.h internally, so they should get the headers for the BC symbols automatically.

Copy link
Collaborator

@albanD albanD left a comment

Choose a reason for hiding this comment

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

Sounds good!
Hopefully it lands cleanly!


#include <ATen/ATen.h>
#include <ATen/NestedTensorImpl.h>
#include <ATen/native/NonSymbolicBC.h>
Copy link
Collaborator

Choose a reason for hiding this comment

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

I though we said that we might as well add this to the general Functions header?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I added them to the general NativeFunctions.h header (since they're part of at::native::) For the OSS builds though, that won't help because we use per-operator headers - so we still need to manually include them here.

That feels a bit weird, but should still accomplish the goal of reducing the risk of internal build failures.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

although - sigh - OSS mobile builds aren't recognizing ATen/native/NonSymbolicBC.h. I probably need to add it to a makefile somewhere.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

hmm @albanD - it looks like the build system is complaining because I'm trying to include a header from aten/native (ATen/native/NonSymbolicBC.h) inside of a header from plain ATen (ATen/NativeFunctions.h).

I think that logically, NonSymbolicBC.h and NativeFunctions.h should probably live in the same location, since they both refer to native variants of the aten API. That makes me think that NonSymbolicBC.h should be moved to live in aten/src/ATen instead of aten/src/ATen/native.

The whole point of the changes in this PR though were to reduce the risk of internal changes being needed, and that would definitely require an internal change, since that header is used internally now 😛.

So my current plan is just to ignore NonSymbolicBC.h entirely in this PR, since it's very unlikely that any of the at::native::*_backward() functions that I'm changing are actually directly called anywhere. LMK what you think!

Copy link
Contributor

Choose a reason for hiding this comment

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

sgtm. keep it separate

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ok!

@pytorch-bot pytorch-bot bot added the ciflow/trunk Trigger trunk jobs on your pull request label Oct 13, 2022
Big-bang PR to symintify **all** .sizes() calls in derivatives.yaml, which will be needed for symbolic tracing.

* with the exception of `split()`, which is tougher to land because it requires internal changes.




[ghstack-poisoned]
Big-bang PR to symintify **all** .sizes() calls in derivatives.yaml, which will be needed for symbolic tracing.

* with the exception of `split()`, which is tougher to land because it requires internal changes.




[ghstack-poisoned]
Big-bang PR to symintify **all** .sizes() calls in derivatives.yaml, which will be needed for symbolic tracing.

* with the exception of `split()`, which is tougher to land because it requires internal changes.




[ghstack-poisoned]
@bdhirsh
Copy link
Collaborator Author

bdhirsh commented Oct 14, 2022

@pytorchbot merge -g

@pytorchmergebot
Copy link
Collaborator

Merge started

Your change will be merged once all checks on your PR pass since you used the green (-g) flag (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

@github-actions
Copy link
Contributor

Hey @bdhirsh.
You've committed this PR, but it does not have both a 'release notes: ...' and 'topics: ...' label. Please add one of each to the PR. The 'release notes: ...' label should represent the part of PyTorch that this PR changes (fx, autograd, distributed, etc) and the 'topics: ...' label should represent the kind of PR it is (not user facing, new feature, bug fix, perf improvement, etc). The list of valid labels can be found here for the 'release notes: ...' and here for the 'topics: ...'.
For changes that are 'topic: not user facing' there is no need for a release notes label.

Rick0317 pushed a commit to Rick0317/pytorch that referenced this pull request Oct 18, 2022
ghstack-source-id: 85d6c20
Pull Request resolved: pytorch/pytorch#86610
@facebook-github-bot facebook-github-bot deleted the gh/bdhirsh/324/head branch June 8, 2023 15:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ciflow/trunk Trigger trunk jobs on your pull request Merged release notes: sparse release notes category

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants