Add 'static_library' runtime::Module #11442
Conversation
|
Thanks @mbs-octoml . I think we go with this as a temp workaround with a mind that the IsDSOExportable and ImplementsFunction likely should go to Artifact. |
|
Yeah, we really need to put some love into that. Collecting all the pieces needed for deployment along with their metadata a la Artifact is pretty clearly needed, though I suspect that will need to be abstract to cover the spectrum from firmware image to dynamically loadable .so to ready-to-call JITed code to tar. I can't help thinking we should also think about build rules guarded by target kinds & attributes, since again there's just so may ways to proceed. |
|
Perhaps we will end up building our own cmake/bazel :p in another time |
(See https://discuss.tvm.apache.org/t/byoc-supporting-cutlass-byoc-with-collage/12796/6 for context, which in turn is part of Collage (https://github.com/apache/tvm-rfcs/blob/main/rfcs/0062-collage.md). This adds a new 'DSO exportable' runtime module representing the contents of a .o file. It allows external codegen toolchains to yield a result which: - Like CSource modules, can be conveyed directly to the final export_library compilation step for linking into the final .so and saved to a know location without risk the underlying code artifact will be lost. - Like DSOLibrary modules, are self contained so that no additional compile-time arguments need be conveyed from the CSource module to the final export_library command line Since this is the third flavor of 'DSO exportable' module, add a Module::IsDSOExportable. Since adding the above, can't resist also adding a Module::ImplementsFunction virtual and calling it from TEComplier to check if an external codegen function actually provided the implementation it promised. Note: - I've left the existing implementation of runtime.load_module alone which relinks .o files to .so files. - Though also contained in the .o metadata, I require static libraries to always carry their list of exported function names. This is all pretty stop gap pending a good rework of TVM to supoprt the notion of artifacts and, perhaps, build rules.
mbs-octoml
force-pushed
the
mbs-collage-static-module
branch
from
79496b5
to
96d4e62
Compare
|
Thanks Tianqi. Let's see if this new fancy bot works... |
|
@tvm-bot merge |
|
Cannot merge, did not find any approving reviews from users with write access on 96d4e62 |
|
Hmff. |
|
Cannot merge, did not find any approving reviews from users with write access on 96d4e62 |
(See https://discuss.tvm.apache.org/t/byoc-supporting-cutlass-byoc-with-collage/12796/6 for
context, which in turn is part of Collage (https://github.com/apache/tvm-rfcs/blob/main/rfcs/0062-collage.md).
This adds a new 'DSO exportable' runtime module representing the contents of a .o file. It
allows external codegen toolchains to yield a result which:
step for linking into the final .so and saved to a know location without risk the
underlying code artifact will be lost.
need be conveyed from the CSource module to the final export_library command line
Since this is the third flavor of 'DSO exportable' module, add a Module::IsDSOExportable.
Since adding the above, can't resist also adding a Module::ImplementsFunction virtual and
calling it from TEComplier to check if an external codegen function actually provided the
implementation it promised.
Note:
relinks .o files to .so files.
carry their list of exported function names.
This is all pretty stop gap pending a good rework of TVM to supoprt the notion of artifacts
and, perhaps, build rules.