tqchen commented on pull request #8472: URL: https://github.com/apache/tvm/pull/8472#issuecomment-881416472
Thanks @manupa-arm . I totally agree that we need to evolve the IR design itself. Constants are indeed special, that would require some careful thinking, I just meant to say that it would take more thoughts and possibly some lessons in less impactful way(e.g. the attribute approach) For example, assume that if we decided that it is a good idea to introduce constant in TIR, there are quite a few set of considerations that needs to go into them: - Q0: What is the interaction model with the high level TIR schedule(e.g. do we need to allocate multi dimensional constant buffer) - Q1: What if we want to express constant that are shared across functions(in which case inling the data may not be the right approach) - Q2: What is the semantics (when the scope itself is special and requires the loading pattern). Different considerations of the above Qs might come to a different conclusions. For example, considering Q1 we may not inline the data into the allocate_const node. It would be important to make an informed choice at some time point and stick with that one and avoid introducing a node then change it later. Our current consideration to constants so far is that most of the transformations happens at the relay level, and at the level of TIR, there are a diverse set of operations involved to allocate, initialize load the constant before use, and it may be hard to converge on a single Q2. As a result, we usually represent constant as a var. So to summarize: - We understand it is important to keep an eye on how do we handle and transform constant that might bring architecture changes. - Because it is hard to make an immediate choice, and we can start with an less impactful approach via attrs, we could unblock by going with that approach. - Once we have learnt enough lessons, we can then come back and revisit this matter, introducing architecture changes to the IR or 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]
