-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[Fix] Fix the logic of the number of nodes checking in op fusion #4074
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
Conversation
zhiics
left a 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.
I saw the previous version would fail if we happen to stop fusing at tuples.
|
@zhiics there is nothing special for tuple. It fail for other cases too - in mergefromto, the groups and functions that will generate is already defined, and it must merge at that point, or stuff will goes out of scope. |
|
@tqchen What kind of test case is in your mind? |
|
would be great if there is a regression test that failed the case before the patch |
|
test case added @tqchen |
|
Thanks everyone. This is now merged. |
…che#4074) * move the number of nodes constraint in op fusion up to the dom tree level * add test case of limiting the max number of ops to be fused * uncomment other test cases
…che#4074) * move the number of nodes constraint in op fusion up to the dom tree level * add test case of limiting the max number of ops to be fused * uncomment other test cases
move the number of nodes checking in op fusion up to the dom tree level, so that the fusion won't be halted in the middle.
@MarisaKirisame @kevinthesun @zhiics