Hey @areusch thanks for elaborating your points and these are all definitely great questions to me!
> 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 Oh I think I get your concern here!! No, we are not building more and more and more frontends to cause fragmentation. Here is the thing - we only need two forms for serialization: - JSON for protobuf-like reliable serialization; - TVMScript python syntax. And we defragment the system by retiring `repr()` for TVMScript. Therefore, as a python user, the only interface you touch is TVMScript python syntax after the RFC landed. Imagine you are a rust user who doesn't want to use python, our proposal makes it possible to develop a frontend in pure rust. And of course, it's not going to be our priority, i'm just stating the possibility. > but if we do follow through and introduce an IRBuilder serialization, that > would count as a fourth way to serialize TIR Ah no, IRBuilder is not serialization, sorry for the confusion. Let's imagine a common usecases in company's prod env where python is strictly prohibited (e.g. on-device training), but our developers wrote most of the operators in python, which is the reality. How do we quickly migrate those operators to C++? Our RFC provides an answer to that - just write a codegen from Doc to C++ IRBuilder :-) Of course again, the RFC aims to open possibilities instead of implementing those functionalities. > 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 Yeah it's definitely fair to say the PR considers Relax a lot. On the other hand, Relax doesn't need this RFC to use TVMScript. Take the current codebase as an example, it's not using the design of this proposal and it's totally fine given it's assuming there are only 2 IRs. Instead, I'm trying to convey is that we build an open infra for any vendors to integrate with their own IRs, which can be represented and compiled in the same IRModule with Relax, TIR, etc. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/74#issuecomment-1155589354 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/74/c1155589...@github.com>
