thanks for summarizing @junrushao1994 . to provide some additional perspective: - I'd really like us to get to a place where we have 1 reliable and readable format to serialize TIR. i don't think we should build all of this infrastructure just to provide a "best-effort" serialization--anything expressable in TIR should roundtrip in any serialization format we provide. there's no reason we have to sacrifice reliability for readability, either--it's just a matter of putting effort into the unit tests. - right now i believe we have 3 TIR formats: `repr()`, TVMScript, and JSON. This RFC looks to provide infra that allows for generation of more formats e.g. so that Python doesn't have to be the frontend for TIR, or so we can leverage other APIs or frontend languages to write TIR. i'm okay with adopting this design to separate indentation from serialization, but if we do follow through and introduce an IRBuilder serialization, that would count as a fourth way to serialize TIR--doing that is only going to make it harder to achieve the previous goal because it splits our human and unit-test attention across multiple formats. i don't see a good reason for doing that laid out in the RFC. - this PR does provide considerations for Relax, although the language spec hasn't been RFC'd or introduced yet. i don't want to block the PR over that, but it's plain that the eventual goal is to leverage this infrastructure for Relax when it lands. then that gets us into a scenario where we have one parser/serializer for Relay and another for everything else. that's also more complex than it needs to be. admittedly, Relax and TIR benefit more from meta-programming than Relay, so it makes sense that the old Relay parser/serializer isn't a great fit here. but if we're going to discuss Relax here, it would be great to see this design considering how it could replace all of the printers in the codebase, not just overhaul the TIR one. anyhow, this discussion can be left for a future time when the Relax merge plan is clearer.
-- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/74#issuecomment-1155312769 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/74/c1155312...@github.com>
