>One of the things missing is a way to say the codegen name in the >runtime.Module without overloading type_key.
I agree. I don't know exactly the best way to proceed here--we likely need another RFC. The limitation is that with C++ runtime, the external compiler in BYOC is expected to produce runnable artifacts. In µTVM, we just expect _compilable_ artifacts. This is a whole different can of worms: it's likely we'll produce a bunch of similarly-formatted `runtime.Module` (i.e. `.o`, `.c`) which may nonetheless need special treatment downstream in the Project generator. Therefore I think it makes sense to identify them somehow to do the export grouping. However, I don't know whether it would make sense to add another `type_key`-like thing or just stick with `type_key` and provide extensible `Module` impls in C++ land. It would be helpful to think through a case where a specialized compiler is required downstream (I.e. something like a CUDA compiler) which produces object code not targeted to `target_host`. >However, a draw-back of this approach is Project-API that consume this will >need to be aware of the folder structure based on composite target. Do we need >that complexity ? The case I mention at the end of the above is the case I'm thinking of where it would be helpful to separate things. The C++ BYOC interface is: "produce a runnable Module in external compiler and serialize/deserialize through binary blob." I think given we don't expect external compilers to produce code that compiles on `target_host`, we should create an explicit namespace that may not include `c` code here. --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-tvm-model-library-format/9121/3) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/5bcbb4fb1d1f8cb1fd34817076677d8f5217714cd903e4d1a0cdf1f452f0d0aa).
