Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support runtime defined function wrapping of library module packed functions #9342

Merged
merged 6 commits into from
Oct 26, 2021
Merged

Support runtime defined function wrapping of library module packed functions #9342

merged 6 commits into from
Oct 26, 2021

Conversation

csullivan
Copy link
Contributor

@csullivan csullivan commented Oct 21, 2021

Targets which compile directly to SO during codegen utilize runtime.module.loadfile_so at runtime to dynamically open these compiled binaries. This flow currently does not have any point of extension in which a runtime can customize the behavior of the underlying LibraryModuleNode. This PR exposes DSOLibrary and extends LibraryModuleNode to utilize a runtime defined PackedFunctionWrapper in order to specialize the calling convention of dynamically loaded function symbols.

This allows a device runtime to then specify a custom DSOLibrary based loadfile implementation:

TVM_REGISTER_GLOBAL("runtime.module.loadfile_hexagon").set_body([](TVMArgs args, TVMRetValue* rv) {
  auto n = make_object<DSOLibrary>();
  n->Init(args[0]);
  *rv = CreateModuleFromLibrary(n, hexagon::WrapPackedFunc);
});

Copy link
Member

@tqchen tqchen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @csullivan some followup comments and I think it is good to go. The main rationale behind is to minimize the API surface getting exposed. and some readability(internal documentation of wrapper semantics)

*/

/*!
* \file dso_module.h
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dso_library.h

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

depending on whether or not we need to expose this interface, we might want to put it back to the cc file to reduce the amount of internal interface. surface.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As Library is an abstraction that is already exposed, I decided to reduce the interface to a helper that returns one instead.

src/runtime/library_module.h Outdated Show resolved Hide resolved
@masahi masahi merged commit f7430e9 into apache:main Oct 26, 2021
ylc pushed a commit to ylc/tvm that referenced this pull request Jan 7, 2022
…nctions (apache#9342)

* Expose DSOLibrary and add documentation.

* Allow runtimes to specialize library module function
wrapping by providing a PackedFunctionWrapper object
at construction.

* Apply clang formatting.

* Use std::function.

* Minimize DSOLibrary interface.

* Add param and return documentation to PackedFuncWrapper type alias.
ylc pushed a commit to ylc/tvm that referenced this pull request Jan 13, 2022
…nctions (apache#9342)

* Expose DSOLibrary and add documentation.

* Allow runtimes to specialize library module function
wrapping by providing a PackedFunctionWrapper object
at construction.

* Apply clang formatting.

* Use std::function.

* Minimize DSOLibrary interface.

* Add param and return documentation to PackedFuncWrapper type alias.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants