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

Support list output for HigherOrderOperators #101986

Closed
wants to merge 5 commits into from
Closed

Conversation

ydwu4
Copy link
Contributor

@ydwu4 ydwu4 commented May 22, 2023

@pytorch-bot
Copy link

pytorch-bot bot commented May 22, 2023

🔗 Helpful Links

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

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

❌ 1 New Failure

As of commit 32d8904:

NEW FAILURE - The following job has failed:

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

Comment on lines 788 to 797
return isinstance(var, TensorVariable) or (
isinstance(var, ConstantVariable) and var.value is None
)

if any(
not _is_supported(var) for var in output.unpack_var_sequence(tx)
):
unimplemented(
"HigherOrderOperator body's output must consist of tensors or None only"
)
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we really need to support None output?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, the reason I added is because the backward logic of autograd.Function can consist of None and we don't want it to graph break. The specific example I encountered is this: https://github.com/pytorch/pytorch/blob/main/test/dynamo/test_repros.py#L2918, where XSoftmax's backward returns None.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm confused, because when we trace the backward, always_restore should be True, so we should never get here

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh I see what's going on

Copy link
Contributor

Choose a reason for hiding this comment

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

Proposal: the logic should be something like:

if always_restore:
   # we don't care about what the output is
   pass
else:
   # we require the output to be a list/tuple of Tensors
   # If it isn't then we raise notimplemented

When always_restore is True, we don't actually care what the output is, because we are never going to use it to construct a subgraph. I don't want to allow non-Tensor output in higher order ops just yet but it might be inevitable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated accordingly.

@ydwu4
Copy link
Contributor Author

ydwu4 commented May 23, 2023

@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

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.

None yet

3 participants