[DISCUSS] Embed more Bound Information into Var or Expr

Development RFC
21

I think option B puts too much limitation that it might be only good for asserting non-neg property. But I can imagine that we need more properties on shapes to perform other optimization. At that time, we will be back on this discussion again whether we add another intrinsic or we will add property to var. For example, people may want to add likely property to a var that expresses the likely size of a shape as a hint to AutoTVM. Allowing var to have properties will benefit in long term, IMO.

I agree with @kparzysz that having such builtin_condition or other helper function for developers to easily add properties to var is good for usability.

22

Let me try to summarize the point. Seems we are converging to a common ground.

I think currently the closest thing possible would be add an assert_expr that assets the non-negative condition to the expression as well as other conditions(chained by and). Alternatively, we can go for the assert_lower_bound, which is more specialized.

assert_expr(x, x>=0)

@haichen would you like to volunteer to summarize, send a formal RFC and land this feature? It would be relevant to dynamic shapes

23

Sure, Iā€™ll follow up with a RFC.

24

another potential use case: https://github.com/dmlc/tvm/pull/3842#discussion_r319835313

25

Another requirement is we may need a reduction infor in Variable, since weā€™ve seen we need to identify if axes are reduce or not in passes. Also orignal Halide has reduce domain infor, we may just need a boolean flag.

@tqchen @yzhliu

26

I think the requirementā€™s valid.

27

MLIR uses solution similar to 2&3: index type It also describes some design rationale and the relation with its affine dialect.

28

Thinking about the problem a bit more during the holiday. Now that we have a flexible Object system whichi supports runtime dynamic checks, one variant of Option A might start to become interesting.

Option A+


class IterVarNode : public Variable {
 public:
   Range dom;

   static constexpr const char* _type_key = "IterVar";
}

Instead of directly enforcing the variable types on the Variable, we could build extension of Var that contains additional information. In order for the visitor/functor to work for this types, we just need to set the default dispatching strategy to

R VisitExpr_(const IterVarNode* obj, Args... args ) {
   return VisitExpr_(static_cast<const Variable*>(obj), std::forward<Args>(args)...);
}

So all the visitors that are based on the functor will work out of the box. This will allow us to introduce a few variants of Vars that can add additional information, while not having to change the rest part of the codebase to accomodate them(things will fallback to normal var) and perhaps it could be complementary to option B

1 Like
29

Iā€™m know Iā€™m quite late to this discussion, but is there a way to embed bound information on variables now.

I know that we have tvm.tir.SizeVar which defines a bound of >= 0, but couldnā€™t find a way to directly embed bound information on variables without writing a pass through TIR.

Thanks,
Anirudh

30

So can we embed bound infomation into te.var now? Maybe assert_stmt?

31

using assert_stmt is a valid approach

32

OK. So can you give an example about using assert_stmt to embed bound infomation? And can this infomation be propagated to simplfy codegen? Thank you so much

33

Itā€™s not supported yet in TensorIR, but will be a good thing to have in the future :slight_smile:

1 Like