10000 [Dynamo][pytree] handle `isinstance(...)` check for polyfilled class by XuehaiPan · Pull Request #146921 · pytorch/pytorch · GitHub
[go: up one dir, main page]

Skip to content

[Dynamo][pytree] handle isinstance(...) check for polyfilled class #146921

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 8 commits into from

Conversation

[ghstack-poisoned]
Copy link
pytorch-bot bot commented Feb 11, 2025

🔗 Helpful Links

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

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

❌ 2 New Failures

As of commit 72d44f2 with merge base 1677a31 (image):

NEW FAILURES - The following jobs have failed:

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

[ghstack-poisoned]
XuehaiPan added a commit that referenced this pull request Feb 11, 2025
x = [1, [2, [3, 4]]]
leaves, treespec, _ = fn(x, y)
# Compiled function returns an instance of the polyfilled class instead of the original class
self.assertIsInstance(treespec, polyfilled_cxx_pytree.PyTreeSpec)
Copy link
Contributor

Choose a reason for hiding this comment

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

My point is, it is wrong for the compiled function to return an instance of the polyfilled class instead of the original class. The compiled function needs to return an instance of the original class.

Copy link
Contributor

Choose a reason for hiding this comment

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

We either need Animesh's polyfill infra for classes, or we need to actually make a TreeSpecVariable in Dynamo that has a reconstruct method. I'd prefer hardening the polyfill infra for classes because that is more generically applicable.

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 compiled function needs to return an instance of the original class.

That is the ideal solution for polyfilling a class. We need to find a way to batch register the Python version of the polyfill methods of the C++ class. cc @anijain2305 about the class polyfill infra design.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

After a second thought, I think polyfilling the methods and using a variable tracker of instance original class during inlining will cause performance issues. Also, it is not easy to polyfill C++ descriptors and support the pybind11 property and read-only property.

The compiled function needs to return an instance of the original class.

We should use the polyfilled class object while inlining the graph and find a way to convert between the original/polyfilled class instances at the graph boundaries.

Copy link
Contributor

Choose a reason for hiding this comment

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

We should use the polyfilled class object while inlining the graph and find a way to convert between the original/polyfilled class instances at the graph boundaries.

Yes

[ghstack-poisoned]
XuehaiPan added a commit that referenced this pull request Feb 11, 2025
[ghstack-poisoned]
XuehaiPan added a commit that referenced this pull request Feb 11, 2025
Copy link
Contributor
@jansel jansel left a comment

Choose a reason for hiding this comment

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

I agree with @zou3519's comments. Polyfill types should not leak into user code.

XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Feb 12, 2025
[ghstack-poisoned]
XuehaiPan added a commit that referenced this pull request Feb 12, 2025
[ghstack-poisoned]
XuehaiPan added a commit that referenced this pull request Feb 12, 2025
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Feb 12, 2025
[ghstack-poisoned]
XuehaiPan added a commit that referenced this pull request Feb 12, 2025
[ghstack-poisoned]
XuehaiPan added a commit that referenced this pull request Feb 16, 2025
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Mar 3, 2025
Copy link
Contributor

Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as Stale.
Feel free to remove the Stale label if you feel this was a mistake.
If you are unable to remove the Stale label please contact a maintainer in order to do so.
If you want the bot to never mark this PR stale again, add the no-stale label.
Stale pull requests will automatically be closed after 30 days of inactivity.

@github-actions github-actions bot added the Stale label Apr 17, 2025
@XuehaiPan XuehaiPan closed this Apr 19, 2025
@github-actions github-actions bot deleted the gh/XuehaiPan/242/head branch May 25, 2025 02:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0