-
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] Simplifier Improvement #2173
Comments
Some of these are not as problematic, because they can be caught by CanonicalSimplify. |
To follow-up on Euclidean divisions, I agree that euclidean div is nice for analysis. The main problem of Euclidean div generation is it is relatively hard to generate efficient low-level code for it, and the developer might make implicit assumption of the semantics of div to be same as LLVM/C. Unless we have a strict analysis of positiveness of the index, in which case the definition of division won't matter. So the case now is we would just stick to trunc div as it is close to machine code, improve the integer set analysis to cover the range of the variable and then revisit the issue later |
By the way, turned out the HalideIR submodule hasn't been updated for a while, so the fix of @xqdan is not in TVM yet. (Unfortunately it doesn't solve my case of incorrect simplification anyway). I would still vote for Euclidean division, and concerning its problems, I would suggest the following plan:
If we choose truncated division, then we should do something with the HalideIR simplifier, because it is used everywhere and is heavily relied upon, and we cannot just replace it with CanonicalSimplify yet. |
Given that truncate div is the current way and the limited simplification works fine for now, I propose us to do the following thing, from pragmatic point of view:
Since this would be a major change to the analysis pipeline, we might want to do it in the next release cycle. |
move to #2588 |
(y - x) - y
. Interestingly,(y - x) - y < 0
is simplified, but(y - x) - y > 0
is not:CanonicalSimplify
works well on this example though.(3*x + y)/3
intox + (y/3)
. Since tvm uses C/C++ truncated division instead of flooring or euclidean division, this is wrong (e.g.x = 1, y = -1
). Recently there was a related issue here. However, instead of disabling another simplification rule I would suggest discussing another option: using Euclidean division in TVM, since the Euclidean definition has some advantages regarding program transformations, and it was originally used in Halide.The text was updated successfully, but these errors were encountered: