-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
[Relay][Op] Remove reverse attribute from reshape and reverse_reshape operators. #7086
Conversation
@vinx13 @icemelon9 @electriclilies can you guys take a look at this PR and let me know what you think? |
Looks good to me! Thanks for getting this up quickly |
Out of curiosity, what is the thinking around versioning of the relay ir ? Would the removal of nodes from the IR require version bumps since whenever I look at relay output I see a version info being printed ? To be clear it appears that this change simplifies a few things and that looks good to me. |
Originally I separate the reshape and reverse_reshape on purpose and also as requested by @tqchen, because the reshape API is closer to numpy's definition and the reverse one is more of a hack to support MXNet. The reason that ReshapeAttr has reverse option is that I want to reuse the reshape type relation function for @tqchen maybe you can comment on this. |
@u99127 I think this change won't remove any nodes from the relay IR, since reverse_reshape just constructs a reshape node with the reverse attribute set to true. There is no standalone reverse_reshape op, only a constructor. |
@tqchen i think we're gonna need your input to make a decision here. The issue Lily mentioned should be resolved. Our two options for fixing it are to consolidate the reshapes as in this PR, or create separate attributes and functions for reverse_reshape. Which do you prefer? |
As a rule of thumb(standardizationover flexibility), we should always keep API def consistent with numpy API when there is a related case in numpy, even though it could mean additional duplications. per https://tvm.apache.org/docs/contribute/code_review.html#deliberate-on-api-and-data-structures We can however, introduce additional attrs to reverse reshape given it is non-standard. I understand that there could be inconvenience here, but the benefits offered by standardization outweights the slight additional eng cost. |
9a3e837
to
11e69ec
Compare
Based on TQs feedback we should keep reshape and reverse_reshape separate. We can do this while resolving the hidden reverse attribute by splitting the type relationship for the two ops. I've updated this PR to do that instead. @icemelon9 can you take another look? |
I think @tqchen and @icemelon9 need to take another look to confirm that these changes look good before we can merge. I believe this solution addresses their concerns while removing the hidden reverse attribute as elegantly as possible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm from my side, @icemelon9 please double check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Please update on Tianqi's comment.
@icemelon9, I made the change recommended by TQ. This should now be ready to merge. |
Currently relay has separate operators for
reshape
andreverse_reshape
however in c++ they were both implemented using shared functions. The weird part is thatReshapeAttrs
has areverse
attribute that was used forreverse_reshape
but not exposed in the python API ofreshape
. This often causes headaches when trying to create a newreshape
operator in a pass from existing attributes, since python doesn't expect areverse
argument. As far as I can tell, there's no reason to have a separatereverse_reshape
op. Consolidating the two and exposingreverse
in python leads to a much cleaner and more obvious API without breaking any tests or use cases.