-
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] Bound for Shape Variables #4486
Conversation
I am not sure if we want to introduce this specialized assertion as a special Expr. It might be a better idea to have it as an intrinsic |
@tqchen @icemelon9 modified per comments, please review again. |
4c250e9
to
105a077
Compare
@tqchen do you have any idea why this is failing (I cannot reproduce locally, and seems to be flaky) https://ci.tvm.ai/blue/organizations/jenkins/tvm/detail/PR-4486/13/pipeline#step-112-log-519 The generated IR is different, but both should be correct. This PR:
previously:
|
find the problem... |
@tqchen @icemelon9 It is ready for review |
@@ -292,9 +292,16 @@ def get_binds(args, compact=False, binds=None): | |||
binds = {} if binds is None else binds.copy() | |||
cfg = current_build_config() | |||
arg_list = [] | |||
|
|||
def is_var(idx): |
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.
rename -> is_var_or_assert_bound
@@ -68,6 +68,41 @@ std::vector<const Object*> GetPath(Expr target, Expr expr) { | |||
return v.path_; | |||
} | |||
|
|||
class BoundRemover : public IRMutator { | |||
public: |
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.
NOTE, we are in progress of updating IRMutators to new style, would be great if we can directly change it here related #4607
@@ -626,4 +626,19 @@ Expr trunc(Expr x) { | |||
return ir::Call::make(x.dtype(), "trunc", {x}, ir::Call::PureIntrinsic); | |||
} | |||
|
|||
Expr assert_bound(Expr value, Expr lower, Expr upper) { |
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.
wrap_assert_bound_on_var
After looking at the set of changes, seems we still have quite a few places where we want to try to assume the properties of a Var. This makes me wonder if we should also revisit the option to bring more information to Variable, but instead of putting them inside Variable, we can subclass the Variable to create special vars(e.g. IterVar) that contains these information. Given that things are easier with the new Object system. See https://discuss.tvm.ai/t/discuss-embed-more-bound-information-into-var-or-expr/4079/28 Of course this does not remove the value of the additional constraint wrapper, @icemelon9 @yzhliu thoughts? |
@tqchen I also feel it would be better than wrapping with a call node |
If we are going to use a Var instead, we will can introduce a special subclass of Variable called ShapeVarNode, which corresponds to shape can contain non-neg info, the solution mentioned in the post will depend on migrating all the Mutator to the new style(which will be done in a few days). Note that will mean we will need to force user to construct shape_var when passing to shapes. |
@yzhliu can you rebase, @icemelon9 @ZihengJiang can you help to do a round of review? |
@tqchen You want me to check current approach in, or directly switch to IterVar implement instead? |
@yzhliu I am fine either way, you can make a decision. Since both are useful approaches and won't affect each other. We might want to think about the name a bit if we are going to sub-class Var (while it makes sense to use IterVar for iterators, it may not sounds too related to shape, perhaps ShapeVar would be a better name). |
close this pr as it is superceded by #4684 |
Background,
https://discuss.tvm.ai/t/discuss-embed-more-bound-information-into-var-or-expr
https://discuss.tvm.ai/t/significant-increase-in-the-amount-of-cuda-code-gen-after-migrating-indexdiv-mod-to-floordiv-mod