junrushao1994 commented on PR #74: URL: https://github.com/apache/tvm-rfcs/pull/74#issuecomment-1151836608
Thanks @areusch for your response! > if TVMScript is a core way in which TIR is used, I'd argue we should treat them conceptually as joined (e.g. TVMScript as the recommended roundtrip text format for TIR). What are your thoughts there? Let's phrase it this way: TVMScript serves as a frontend of easily constructing and manipulating TIR, Relax and any third-party IRs. It offers readability, type checking, metaprogramming, etc. In terms of serialization, my standing is that reflection-based JSON serialization is still the best way to go as it's the least error-prone if we don't need readability and manipulability. > what do you mean by "reliable" here? if they're truly roundtrippable, aren't they both reliable? just trying to understand :) In practice we did notice that there could be some ad-hoc issues (which are definitely fixable, not a big deal, so I'm not saying it's not good) that probably be overlooked when implementing the parser. For example, @mbs-octoml fixed a dtype issue very recently (https://github.com/apache/tvm/pull/11224). Instead, reflection-based JSON serialization mechanism in TVM is definitely less bug-prone because it doesn't need to handle edge cases - the downside is that it's almost unreadable though. > Is the goal then that you'd be able to serialize an IRModule which contains fragments that need to be repeated via meta-programming? then, if you did this using a host language's IRBuilder, you could quickly write some meta-programming steps in that host language to expand the program. Yeah with metaprogramming we are able to write bunch of code that require host-language control. The next RFC is all about metaprogramming so stay tuned :-) -- 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]
