Your proposal is reasonable from perspective of existing Chainer users looking for deployment solution. However, I see little benefit from TVM side.
First of all, compared to other framework like PyTorch, the number of Chainer user had been very tiny even during Chainer was in active development. Now that Chainer development is in maintance mode, I would estimate the number of active Chainer users is close to zero. So "bringng Chainer users to TVM" doesn't really appeal to us. The only reasonable use case is the need to deploy existing Chainer models. However, developing something entirely new in TVM to support such a legacy use case doesn't seem right to me. ONNX should be a good fit for Chainer users (who do not want to switch to PyTorch for some reason). Take a look at chainer-compiler https://github.com/pfnet-research/chainer-compiler. They use ONNX as a bridge between Chainer and their compiler. That means ONNX is "the" official IR adopted by the Chainer team. It also means their support of ONNX export should be good. You are correct in that chainer-onnx is not really in a good state, so the chainer-compiler team is developing a new ONNX export tool (actually two, see "ch2o" and "elichika" in https://github.com/pfnet-research/chainer-compiler/tree/master/chainer_compiler). Chainer -> ONNX path enables using our relatively mature and well supported ONNX frontend. If you find a problem in Chainer to ONNX export, you should report or send a patch to them. If they are not supporting ONNX export either, maybe it is time for you to reconsider your decision of continuing to use Chainer. Rewriting your models to PyTorch should be more straightforward and better decision than developing another Chainer exporter or converter in TVM. [quote="ANSHUMAN.TRIPATHY, post:4, topic:6129"] Chainer has highly flexible training framework(as it support define-by-run methodology), i am pretty sure there will many technical challenges in implementing the Frontend. This will give us opportunity to test the TVM Relay strength for express-ability (or in other terms versatility). [/quote] You need to be more specific than "pretty sure". Chainer's flexible API has been adopted by other frameworks and it is not unique to Chainer anymore. One of the interesting challenges when converting from "dynamic" frameworks is control flow. For that, we already demonstrated in our Torch frontend. Note that if you use tracing, by definition you lose control flow and tracing only frontend is not really interesting. Preserving control flow is highly non trivial, you need to start by parsing Python source code to get an Python AST. (This is what Torchscript and chainer-compiler above do to preserve control flow) Are you prepared for this? Even if you are, it is out of scope from TVM anyway. If you really want to develop this frontend, you can develop it as a utility library building on top of TVM. It doesn't have to live inside TVM repo, since everything frontend code need is available in "userland". --- [Visit Topic](https://discuss.tvm.ai/t/introduce-new-frontend-for-chainer/6129/7) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/dee29689881be71667de8293c6424c000dfad201e9d47302f08375a9a5507ec3).
