Hi @areusch, Thanks for the explaination. Lets discuss this a little further. I think we need a good reason if we are to maintain the same piece of functionality in two places – namely as LLVMMetadataModule and CSourceMetadataModule.
true, though right now that’s only required if you are using BYOC on µTVM.
Not exactly, when we go down the metadata module approach, every IRModule that has a target “llvm” or “c” (with system-lib and runtime=c) will produce at least two runtime modules. Thus, we would need to use export_library to link the artifacts produced by saving such runtime modules. I think this is what we agreed here when making uTVM to support multi-module builds (though the discussion was about external modules) : External modules in uTVM - #6 by manupa-arm. I think module.save should be used for unit testing and debugging.
I think that a C frontend also requires a bit more configuration than linking object files together into a library.
Maybe, can you give an example what are additional configurations that we would need to give in the two scenarios, we would end up when the target is “llvm”?
-
S1 : metadata.c, lib.o
(this is what we would end up if we have (only) a CSourceMetadataModule) -
S2 : metadata.o, lib.o (this is what we would end up if we have LLVMMetadataModule)
I would like to get to a position where if you are using topi schedules with LLVM-supported targets, TVM contains all of the dependencies you need to build object libraries.
So this is regarding the creation of lib.o (the artifacts created out of lowering the main IRModule) which is still be the same irrespective of the presence of the metadata module.
so long as you’re not generating code that deals with hardware specifics outside the ISA, you shouldn’t need to tell TVM about your target compiler where LLVM supports it.
Dont we need that for the linking the two artifacts ? Moreover, tvm involves the llvm pass manager to convert the the built LLVM IR (.ll) to object file. Will it be too much to assume the presense of at least clang (if not gcc or gcc varient for target architecture) in the machine ?