tqchen commented on pull request #8472:
URL: https://github.com/apache/tvm/pull/8472#issuecomment-881068098
Thanks everyone. While it is indeed possible that adding a new TIR node
won't impact the current flow, changing the IR data structure itself is indeed
a major architecture change that we need to think more thouroughly. Since a
stable set of IR data structure and semantics would help us in the long run.
Just want to clarify the situations. We can also roughly map the solutions
to:
- C3: Introduce a new IR node
- C2: embed into attrs, but allow attrs to refer to the IR node
- C1: embed as meta data and use instrinsics to refer to it.
For the particular application in mind usually, C3 certainly brings the
least amount of indirection. However, it also brings deeper surgery to the IR
architecture itself. In the extreme case, one might fall into a that introduces
new IR node for each kind of application to touch meta-data.
The main possible problem in C2 is that we want to make sure meta data in
attrs remains constant during rewrite, so that the `my_param_var` won't get
rewritten to something else, and passes does not need to consider the context
to check if all variables are bound.
C1 is the approach that falls within the current architecture of meta data
handling. While I agree that it may not be the most direct option at the
moment, it will bring the least amount of impact to the TIR architecture itself.
Popping up a level, we want to carefully think about the general need to
referring to a constant meta data, and perhaps build some more native mechanism
than C1, but also generalizes the particular case of allocate_const. For
example, maybe we want to allow relay and TIR to share a same mechanism of
such constant data reference. That is the long term solution that we might want
to think about along the directions(e.g. bring the constant map as part of
IRModule).
--
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]
