[RFC] SaveToFile(file_name, format) expected behavior

Development RFC
1

In the context of the command-line driver PR, 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

2

Also cc @zhiics for comments.

1 Like
3

I think another situation where SaveToFile is hard is when we have multiple modules imported. For example, a MetadataModule could contain a DSOModule and one or more CSourceModule/JSONRuntimeModule. It seems a bit hard to save them out as one file for compilation though.

I think this is not quite directly related to the problem you solve to but it could complicate the problem.

4

I see what you mean. It might be the case, for some modules, they don’t offer any export format, which means in my P2 (above) they would have an empty list as “supported format to export files”.

5

I’m thinking about opening this as an issue on GitHub. Are there any other comments? maybe from @jroesch @thierry - feel free to add others.

6

SaveToFile is more of a low-level API, that is not very consistently defined.

For most multiple module case, we use mod.export_library instead.

And the logic is used as follows:

  • LLVM/C module use SaveToFile to save the right source code.
  • Other modules, use SaveToBinary to serialize the ptx/opencl into the binary segment of the source code.

My take is that given we encourage mod.export_library in most of the time. We do not have to complicate the SaveToFile API and can keep things.

We can try to make things consistent, by only supporting the correct format, and report error when file format is not supported.

User should always use mod.export_library to get a packaged version of the output.

7

Agreed. That is exactly the point.

The main use for the sake of command line driver is to be able to export files that will help to understand what is going on when using a particular target. That is why it is useful, for example to be able to export the ll file when using llvm, for example.

2 Likes
8

I think it makes sense to be stricter. :+1: