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

[Unity][Op] Allow the argument to call_tir to be a var bound to a tuple, not a tuple literal #15971

Closed
wants to merge 2 commits into from

Conversation

slyubomirsky
Copy link
Contributor

In response to the issue in common subexpression elimination noted in this forum post, this PR fixes the case noted by allowing call_tir and its variants to correctly handle the case where they are passed a variable bound to a tuple of arguments, rather than a tuple literal. This was an easy change to make and corresponds to user expectations.

In principle, we could address the issue highlighted in other ways, such as by changing common subexpression elimination to avoid doing elimination inside call_tir calls or treating call_tir as a special case during normalization. I went with this approach because I believe it to be simpler; however, we may consider other approaches if it is absolutely essential that the argument be a tuple literal. (I would argue that that would not be a particularly good design.)

Copy link
Contributor

@quic-sanirudh quic-sanirudh left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for the quickfix

@Lunderberg
Copy link
Contributor

This may be a duplicate of #15916, which also resolves the analogous problem for FuseOps, RewriteDataflowReshape, and FoldConstant.

@quic-sanirudh
Copy link
Contributor

This may be a duplicate of #15916, which also resolves the analogous problem for FuseOps, RewriteDataflowReshape, and FoldConstant.

Oh nice, this is great, thanks for this. I was running to issues in the some of the same passes when testing locally, and so I was starting to work on a fix to follow up this PR, but looks like they're all fixed in #15916, that saves me a bunch of time 😄, so thanks again for that.

@slyubomirsky
Copy link
Contributor Author

Didn't see it, yep, they're duplicates. There is one case that the other PR misses so hopefully that can be updated.

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.

3 participants