[Runtime] Introduce runtime module property

[sunggg]

Currently, we only classify whether the runtime module is DSO-exportable.

This PR further classifies each runtime module into the properties as follows:

• kBinarySerializable: we can serialize the module to the stream of bytes. CUDA/OpenCL/JSON runtime are representative examples.
• kRunnable: we can run the module directly. LLVM/CUDA/JSON runtime, executors (e.g, virtual machine) runtimes are runnable. Non-runnable modules, such as CSourceModule, requires a few extra steps (e.g,. compilation, link) to make it runnable.
• kBinaryExportable: when the module is kBinarySerializable and kRunnable, we consider this module as binary exportable. A binary exportable module can be integrated into final runtime artifact by being serialized as data into the artifact, then deserialzied at runtime. This class of modules must implement SaveToBinary, and have a matching deserializer registered as runtime.module.loadbinary_<type_key>.
• kDSOExportable: we can export the module as DSO. A DSO exportable module (e.g., a CSourceModuleNode of type_key 'c') can be incorporated into the final runtime artifact (ie shared library) by compilation and/or linking using the external compiler (llvm, nvcc, etc). DSO exportable modules must implement SaveToFile.

Please note that kDSOExportable is a mutual exclusive property with kBinaryExportable.

To represent each category, the following status bits are defined.

namespace property {
/*! \brief Binary serializable runtime module */
constexpr const uint8_t kBinarySerializable = 0b001;
/*! \brief Runnable runtime module */
constexpr const uint8_t kRunnable = 0b010;
/*! \brief DSO exportable runtime module */
constexpr const uint8_t kDSOExportable = 0b100;
/*! \brief Binary exportable runtime module */
constexpr const uint8_t kBinaryExportable = kBinarySerializable | kRunnable;
};  // namespace property

Edit based on the review

This PR further classifies each runtime module into the properties as follows:

• kBinarySerializable: we can serialize the module to the stream of bytes. CUDA/OpenCL/JSON runtime are representative examples. A binary exportable module can be integrated into final runtime artifact by being serialized as data into the artifact, then deserialized at runtime. This class of modules must implement SaveToBinary, and have a matching deserializer registered as runtime.module.loadbinary_<type_key>.
• kRunnable: we can run the module directly. LLVM/CUDA/JSON runtime, executors (e.g, virtual machine) runtimes are runnable. Non-runnable modules, such as CSourceModule, requires a few extra steps (e.g,. compilation, link) to make it runnable.
• kDSOExportable: we can export the module as DSO. A DSO exportable module (e.g., a CSourceModuleNode of type_key 'c') can be incorporated into the final runtime artifact (ie shared library) by compilation and/or linking using the external compiler (llvm, nvcc, etc). DSO-exportable modules must implement SaveToFile. In general, DSO exportable modules are not runnable unless there is a special support like JIT for LLVMModule.

To represent each category, the following status bits are defined.

enum ModulePropertyMask : int {
  kBinarySerializable = 0b001,
  kRunnable = 0b010,
  kDSOExportable = 0b100
};

cc. @tqchen

[tvm-bot]

Thanks for contributing to TVM! Please refer to the contributing guidelines https://tvm.apache.org/docs/contribute/ for useful information and tips. Please request code reviews from Reviewers by @-ing them in a comment.

• cc @areusch _{See #10317 for details}

_{Generated by tvm-bot}

[tqchen]

let us use int to keep things simple, make it an enum

enum class ModulePropertyMask : int

[sunggg]

Used enum ModulePropertyMask : int instead for implicit casting.

[echuraev]

Thank you for the PR. I have one question. Where is it planned to use these properties? In this PR I see only adding these properties but no use-cases. Probably a simple unit test will be helpful to understand what should be achieved after enabling these properties.

[tqchen]

I think a good first step is to replace the current usage of the IsDSOExportable in the module.export_library using the flag, and report error when we encounter something that is neither DSOExportable or BinarySerializable

[sunggg]

Thank you, @echuraev for the review. As @tqchen pointed out, this PR changes the way we achieve the same functionality but with a more refined manner. This PR was motivated by the discussion in my outstanding PR #14337 about roundtrip-abilty and with this change, we can offer more systematic error message when we cannot guarantee this.

I initially thought passing the existing tests would be sufficient since it does not introduce any new behavior or feature. But, if you think it is still good to have a unit test about it, I can definitely add one. :)

[junrushao]

This is a really comprehensive summary and I believe it will generally be quite useful to anyone (including me) who wants to understand runtime.Module in depth. @sunggg @tqchen shall we put it somewhere in the official tutorial?

[echuraev]

@sunggg Thank you for your reply! It is a nice summary and the reason why we did it starts to be much clearer for me. I'm ok with current tests but agree with @junrushao that creating some documentation might be very useful.

[sunggg]

@junrushao @echuraev Thank you for the suggestion. Addition to the official tutorial also sounds great to me.

By reflecting @tqchen's suggestion, I also added some unit tests and assertion in export_library.
Hope this helps!

[mehrdadh]

@tvm-bot rerun

[echuraev]

LGTM. Thanks!