In the context of the [command-line driver PR](https://github.com/apache/incubator-tvm/pull/6302), it was possible to notice some issues in the way different `ModuleNode` subclasses - such as `ONNXSourceModuleNode`, `StackVMModuleNode`, `LLVMModuleNode`, etc. - behave, with regards to `SaveToFile`.
**Example:** `LLVMModuleNode` will fail in case you ask for an unsupported format, and give an error. Other classes like `StackVMModuleNode` will simply ignore the format you ask and give you a create a file (path from `file_name`) with binary serialization of the module. This RFC intends to get a common understanding on what we should expect (or improve) from `void SaveToFile(file_name, format)`. **Problem** Based on the context above, it was possible to identify two related problems: * P1: Different classes will behave differently for the requested formats * P2: It is impossible to know beforehand, which formats are supported by each class **Proposed Solutions** To solve P2, we can (1) implement a new attribute for the `ModuleNode` class, that reports what are the expected formats that `ModuleNode` supports, as a list of strings, and (2) provide a Python API for the supported formats to be retrieved, as a list. Addressing P1 then consists of improving `ModuleNode.SaveToFile` then should only accept `format` that are on that supported list, and fail with error in case there is a legitimate issue generating the file or in case the format is not supported. Some rework will be needed on existing classes to make this uniform among different `ModuleNode` implementations. **Final Remarks** I think this is fairly small topic, but wanted to open this discussion as this will affect existing Module implementations. cc @comaniac, @tqchen, @ramana-arm --- [Visit Topic](https://discuss.tvm.ai/t/rfc-savetofile-file-name-format-expected-behavior/7741/1) 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/ee4abd774bed8527698a0c069c9026f04b5790a790698cbe4875fc56930cfcf7).
