manupa-arm commented on pull request #8472: URL: https://github.com/apache/tvm/pull/8472#issuecomment-883568689
Hi @tqchen, Thanks for explanation of the concerns. I agree that they are valid concerns. > Q0: What is the interaction model with the high level TIR schedule(e.g. do we need to allocate multi dimensional constant buffer) ? By this if you mean what we currently know as TE, then we can bound the constants post-scheduling to the TIR, Can't we ?. I may not have the full picture in a world where whole of TE disappears. An elaboration would be more than welcome here :) . > 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) While params are one of the type of constants that could appear in a TIR PrimFunc, I feel global constant sharing is a subsequent optimization for merge duplicate global constants. (Similar to LLVM's ConstantMerge). Q2 is seems a bit broader point that is based on there would be different interpretation for Q1 and Q0. > 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. If the constants in consideration are params, then there is a choice whether to inline them or not. However, if the constants are generated in the process of compilation, we might need something like ConstantMerge, to achieve the objective of Q1. I generally agree its better to know most possibilities before defining a IR node, but its not clear to me how varied the representation of the constants could be in TIR as a IR node. > 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. We could also use transformations at a TIR level by enabling the representation of constants in TIR as well. For the semantics, how will it differ from a tir.allocate apart from the buffer_var being read-only (non store-able) and has values loaded by definition ? I dont particularly see mechanics of Q1 having an impact on how constants should be defined in TIR. Let's say if we did decide to delay C3, between C1 and C2, why is C2 different from loading an input var that matched to a buffer_var, where the latter does not need an intrinsic like tir.get_input_param() ? -- 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]
