Created CSourceMetaData module for model metadata

[manupak]

• Currently, there is a MetaData module to capture constants
  conditionaly if the runtime modules implement const init
  PackedFuncs. However, this one relies on a load process
  in which the metadata is created on volatile memory that
  may be not usable in uTVM environments.
• There is a need for model level metadata that is valid
  across all runtime modules such as the func registry
  when creating a system-lib.
• This commit implements a CSoureMetaData module to hold
  func registry that collects function names from the
  runtime module and generates a c source file to be
  linked with final artifact.
• Modified and added export_library for utvm

Discuss : https://discuss.tvm.apache.org/t/csourcemetadata-module-a-csourcemodule-to-hold-function-registry-for-utvm/8554

[manupak]

@areusch@tqchen@mbaret@zhiics
Please take a look when you have a minute :).

[zhiics]

half way done. will review the module part later.

[zhiics]

Do we need an array? it seems that a csourcemodule is only one function though.

[manupak]

When we target "c", in it can have more than one function which also uses the same CSourceModuleCreate interface. See codegen_c_host.cc

[areusch]

did an initial pass

[manupak]

@tqchen@areusch@zhiics , I ve addressed all the comments and aligned with what we discussed in the RFC.
Can you have another look when you have time? If its OK, please approve explicitly. Thanks!

[areusch]

@manupa-arm looks like we are converging now. just a couple more things I want to resolve

[zhiics]

why do we need to extract csource_module? Originally the target module is a DSOModule. The other external modules are parallel to it like the following:

MetadataModule
-- DSO
-- C source1
-- C source2
-- other type of modules

Each sub module manages its own constants. Now we combine c source modules to the DSO. What's the advantage of it?

[areusch]

with C runtime on bare metal, we have no dlsym, so we must assemble a string-to-function pointer lookup ourselves. that's why we pass them to metadata module here

[manupak]

Yes, that is correct.

We would only need the current MetadataModule (which is non-DSOExportable) if the runtime module's requires the constants to be copied in the init process -- which is something we dont want in bare-metal. In-fact if the non of external modules have constants extracted (e.g., ethos-n and ethos-u will be managing their own constants -- truly with the current approach each sub module are copied with their constants from the MetadataModule by the MetadataModule), we dont even want MetadataModule (which is non-DSOExportable) get imported to the module hierarchy.

Moreover, the purpose of the c-source metadata module is to provide an global entity for all DSOExportable modules a place to hold global data of the model. Initially its the function registry which @areusch describes here. These metadata is accessed via linkage and therefore does not require an explicit copy.

[manupak]

Ping @areusch@zhiics.
Let me know if you have any more concerns, I ll be disappearing for holidays from tomorrow.
Thus, would like to address if there is anything today. Thanks!

[areusch]

I think all my concerns are addressed. @zhiics anything further?

[zhiics]

Thanks @manupa-arm@areusch