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 :-) -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/74#issuecomment-1151836608 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/74/c1151836...@github.com>
