Thanks for the great proposal. @hcho3, I followed your [script in
github](https://github.com/hcho3/relayviz) and noticed it missed a case when
operator being "Call"ed is a function.
Adding some code within "Call" condition can generate graph with each function
singled out.
```
[quote="tqchen, post:4, topic:6334"]
The addtional cost for memo is not taking a lot of locs
[/quote]
Note that in addition to the memo logic itself, we can also remove
`VisitExpr(const Expr& expr)` override in the derived classes (which to me
seems only exist for memoization), and hence the d
Given that the ExprFunctor also have additional arguments(besides the first
argument), it is unclear how do we define such Memoization, unless we restrict
the arguments to only contain the single one. The addtional cost for memo is
not taking a lot of locs, so I think either way is fine(consi
hmm, then does it make sense to have a another derived class, say
`MemoizedExprFunctor`, that does have a memo logic built in, for a simple use
case in derived classes that requires memoization? The PR I saw today could
derive from this instead of ExprFunctor, for example.
Basically for encap
ExprFunctor is a more generic base class for dispatching, while itself can be
used to build recursive visitors, the visitor is not the only use case for the
ExprFunctor. For example, we use the functor to build a dispatching Rewriter
callbacks in the recent non-recursive vistor.
Memoization
Currently I'm about to merge a PR
https://github.com/apache/incubator-tvm/pull/5310 which adds memoization logic
for `ExprFunctor` in two different derived classes.
I've also noticed that there are many places in the code base that have the
same duplicated memoization logic for `ExprFunctor`
