manupa-arm edited a comment on pull request #8472: URL: https://github.com/apache/tvm/pull/8472#issuecomment-881193901
Thanks everyone! great discussions. I ll first reply to @areusch comments. > believe your primary goal as I understand it is to encode the constant data in TIR so that post-scheduling visitors can modify the IR and the data based on whole-program analysis prior to exporting the model parameters, is that correct? it would be great to capture this in an e.g. RFC or design doc. Yes this is correct. Once we conclude the discussion, we are happy to create a pull request to tvm-rfcs. For the discussion, I feel its better to have it here rather than going back and forth via discuss forum -- so its easier for reader to follow the discussion later. > I'm not sure what the right IR construct is, but perhaps we could consider it in terms of this longer-term goal rather than the immediate goal of extracting --link-params from TIR constants. Agreed, though --link-params kind of mean to bind the params to the IR --> then to the codegeneration of operators itself (unless they are pooled and pulled out). Yes, the subsequent PR will support the code generation as well for linked constants :). > Given constants are not currently encoded in post-schedule TIR, I think the main case we need to consider is when a pass expected to find params by inspecting a PrimFunc param, but now needs to also inspect something else. I dont believe this (a pass expected to find params by inspecting a PrimFunc param) is possible until we embed the constants in TIR for TIR passes. > We also need to consider how other executors could be coupled with passes that modify the constant data. We don't want to create special cases in TIR for specific executors when we don't need to. Agreed. Actually, the work we are trying to do here makes the params insensitive to the executors when the user wants them linked to the operators. Therefore, we dont see how embeddeding constants to TIR is executor specific. -- 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]
