@manupa-arm yeah exactly--the main difference is that µTVM wants a static library by default. i'm okay with O1 (reusing export_library) so long as we don't need to change export_library too much to accommodate µTVM (i don't believe any changes are needed, after reviewing it here).
for my autotvm prototype using µTVM RPC server, I made such an `fcompile` that calls `tvm.micro.Compiler.library()`: https://github.com/areusch/incubator-tvm/blob/utvm-runtime/python/tvm/micro/build.py#L217 i'll merge that next after the QEMU regression is finished or potentially concurrently. feel free to hack on it if it can be made useful for this situation. re: PackImportsToC: I'm not sure this is exactly the intended use of `export_library`, but it seems like if you had a CSourceModule that imported a single LLVM module (containing the binary blobs as const global symbols), you could write an `fcompile` that accepted both `.c` and `.o` and produced a static library `.a` just as the autotvm does now. that seems fine from a µTVM perspective. the advantage would be that it would get around the slow compiler parse times that people have reported. we can also create an e.g. `PackConstantsToLLVM` to specialize for binary blobs with individual global symbol names. I think so long as the binary blobs are const primitive-typed symbols, most linker scripts should place them in flash, correct? we should definitely make sure we are generating blobs that stay in flash, so we don't blow up the pre-main() flash-to-ram loop. --- [Visit Topic](https://discuss.tvm.apache.org/t/external-modules-in-utvm/7993/9) 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/405ddc03298862299a32f87a8dad3f79c7c23ddf213705b681211755534aac58).
