You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@tvm.apache.org by GitBox <gi...@apache.org> on 2021/10/11 08:41:53 UTC

[GitHub] [tvm] PhilippvK opened a new pull request #9243: Add runtime.ModuleGetFormat method enabling export of BYOC generated sources which require a .cpp/.cc file extension

PhilippvK opened a new pull request #9243:
URL: https://github.com/apache/tvm/pull/9243

## Motivation
I ran into the issue that I need to use C++ features in a BYOC generated kernel which is tricky to achieve because those are typically exported as `.c` files.

I am aware of the possibility to force `gcc`/`g++` to threat all input files as C++ but this solves the issue only partially and is not really intuitive. Renaming the file names e.g. changing the file extension manually after the export via MLF is if also a workaround which does not work out for me.

### Solution(s):
I came up with two rather simple solutions to solutions to solve the explained limitation in the ability to choose the correct file extension for kernel files written by a custom codegen and implemented the first one in this PR because it should add minimal complexity to the TVM codebase which might be desirable:

1. Each `CSourceModuleNode` already has a `format` field which can be set in the constructor. Currently it can not be accessed by other classes but this can be easily solved by adding a getter and the respective python hooks for that property. This information can then be accessed by i.e. [`model_library_format.py`](https://github.com/apache/tvm/blob/main/python/tvm/micro/model_library_format.py) to determine the file extension for the exported kernel. It would also be possible to use this interface for other types of modules in the future.

2. Introduce a new class `CppSourceModuleNode` which is essentially a copy of `CSourceModule` with the only difference being the the the `module_key` which may then be used to choose a file extension in the aforementioned python functions. This sounds like much redundant code to me and also has less flexibility compared to option one as we would have to stick with either a `.cc` or a `.cpp` file extension for every modules of that type.

### Open questions/thoughts:

I realized that the module format `cc` is currently already used by the `CSourceCrtMetadataModuleNode` declared in [`source_module.cc`](https://github.com/apache/tvm/blob/main/src/target/source/source_module.cc#L331):

```
auto n = make_object<CSourceCrtMetadataModuleNode>(func_names, "cc", target, metadata);
```

This does not really make sense to me and especially makes some AoT and Model Library Format related pytests fail because the metadata module now being exported as `.cc` instead of `.c` as explaind the the previous paragraph. Let me know if I should add the fix these Makefiles to this PR and keep the module format for the `CSourceCrtMetadataModuleNode` defined as `cc` or if should work around this issue instead by changing the module format of that file to `c`?
I did not yet come up with new test cases which exercise the introduced changes to the MLF export as this would very likely result in a need to add a new dummy BYOC module which uses the `cc` format instead. During development I just patched the example [`codegen_c`](https://github.com/apache/tvm/blob/74aa856941ff31859d305b8ce564de23fb39ae2f/src/relay/backend/contrib/codegen_c/codegen.cc#L274) to export C++ kernels instead which worked fine,

I decided against an RFC for this discussion as only a couple of lines are added to the TVM codebase to realize this feature. Let me know if I should make this a (Pre-)RFC instead. Otherwise I would be happy for any feedback and answers to the remaining questions introduced in the last section.

---

CC @areusch @Mousius @giuseros @manupa-arm

--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org