-
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
[ARITH][BUGFIX] Fix a bug of iter map floormod(x,2) simplify #14571
Conversation
Thanks for contributing to TVM! Please refer to the contributing guidelines https://tvm.apache.org/docs/contribute/ for useful information and tips. Please request code reviews from Reviewers by @-ing them in a comment.
Generated by tvm-bot |
cc @Lunderberg @junrushao Please revisit some of the previous floormod(x,2) rules to see f there are similar kinds of problems. cc @wrongtest-intellif |
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! This really took me a while to understand why this rewriting is not correct :-)
The case
{i: T.Range(0, 1024), ax0: T.Range(0, 1024), j: T.Range(0, 1023), ax0: T.Range(0, 1024)} Currently in iter map we could check |
That is my guess as well. Would be great to confirm if that is the case. We should prioritize the iter map rewrite and avoid mutate sign of iter map expressions. |
Thank you for finding the error there. The rewrite were initially introduced to allow simplification of cases of I agree that the |
I think the gist is that we should avoid to rewrite |
Update: We also removed the rule that simplifies (x + 1) % 2 => 1 - x % 2 This hopefully can recover the failed case in The particular rewrites is not that useful in software pipeline because all the is are going to be unrolled Some take aways
|
Thank you, and that makes sense for now. I'm seeing if I can find the expression that required this simplification step in order to enable a cancellation, but however it gets re-implemented should avoid the breakage in iter map simplification. |
Would also be good to put up such expressions in TVMScript so we have context for new rules For example, some of the (i +1) %2 expressions do not need simplification mainly because they are in an unrolled loop and the expression will become constant later |
This PR fixes a previous bug introduced in itermap detection. Specifically, y - (x % 2) were simplified to y + (x % 2) - 1. Which is wrong. The working rule is y + ((x + 1) % 2) - 1, but that rule will change the base iterator which is not desirable here. We also removed the rule that simplifies (x + 1) % 2 => 1 - x % 2 as benefit is minimal and it introduces extra negative co-efficients that hurts analysis in general (as negative co-efficients are harder in many cases).
This is merged. Thanks for digging into the analysis! |
…lify (apache#14571) This PR fixes a previous bug introduced in itermap detection. Specifically, y - (x % 2) were simplified to y + (x % 2) - 1. Which is wrong. The working rule is y + ((x + 1) % 2) - 1, but that rule will change the base iterator which is not desirable here. We also removed the rule that simplifies (x + 1) % 2 => 1 - x % 2 as benefit is minimal and it introduces extra negative co-efficients that hurts analysis in general (as negative co-efficients are harder in many cases).
…lify (apache#14704) cherry-pick apache#14571 to v0.12.0
This PR fixes a previous bug introduced in itermap detection.
Specifically, y - (x % 2) were simplified to y + (x % 2) - 1. Which is wrong. The working rule is y + ((x + 1) % 2) - 1, but that rule will change the base iterator which is not desirable here.