Lunderberg commented on code in PR #16560:
URL: https://github.com/apache/tvm/pull/16560#discussion_r1489682462
##########
src/tir/schedule/primitive/blockize_tensorize.cc:
##########
@@ -738,6 +739,28 @@ StmtSRef Blockize(ScheduleState self, const
Array<StmtSRef>& blocks, bool preser
return result;
}
+class TensorIntrinSimplifier : public arith::IRMutatorWithAnalyzer {
+ public:
+ static PrimFunc Apply(PrimFunc func, arith::Analyzer* analyzer) {
Review Comment:
> as u mentioned in
https://github.com/apache/tvm/pull/13299#issuecomment-1942085566 , perhaps its
better to simplify in prim_func level, I chose to implement a stmt simplifier
because it may be more useful. The rationale is that stmt is more fine-grained.
Good point. Thinking on it again in the morning, I think we should avoid
having the simplify function for `tir::Stmt` altogether, *because* it is more
fine-grained. That is, its existence would encourage simplifications to be
performed for specific statements, even though those statements might not be
the outer-most.
> But we can implement a prim_func one as well, should we keep both stmt and
primfunc simplifier or just maintain only one of them?
I think having a simplifier for a `PrimFunc` would be better, because it
encourages developers to simplify with the full context of a statement. The
functionality already exists
[here](https://github.com/apache/tvm/blob/main/src/tir/transforms/simplify.cc#L145),
and would just need a wrapper function to expose `StmtSimplifier::Apply`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
