Hi all,
I look into tvm source code and wonder how tvm codegen specific target machine code.
with transform.PassContext(opt_level=3):
graph, lib, params = relay.build_module.build(mod, target, params=params)
lib.export_library("./testnet.tar")
Take arm
as an example, relay.build_module.build
returns lib
as module, I think it is the container of tvm module. And lib.export_library
interpret the Module
into machine code as shared library
and compress it as *.tar
file.
- How
export_library
codegen the arm machine code?
I tried to read the source code and find the calling stack as follows:
export_library -->PackImportsToLLVM -->CodeGenBlob
However I don’t find where CodeGenBlob
map LLVM IR into corresponding machine code
- how
export_library
codegen shared library?
Does the LLVM
do anything for us?
Thanks for any reply!
hi @chiuchiu,
export_library
links modules with type llvm
or c
(termed “DSO-exportable”) using either the system linker or one specified with fcompile
. CodeGenBlob handles the rest–those which are not DSO-exportable. The other types of Module, we expect there to be a subclass of Module available at load_library
time. That subclass is expected to read a portion of the binary data from CodeGenBlob and return a copy of the original Module.
LLVM is used to generate code for llvm
modules.
Hope this helps,
Andrew
Hi @areusch,
thanks for your reply!
Can you say more about “DSO-exportable” which I don’t understand what it means?
I think, take ‘arm’ as an example, tvm relay IR will transform to llvm IR, but I don’t know how can the llvm IR compile to binary code since I don’t find any *td file, tableGen or anything like llvm backend.
Can you point me some clue?
Thanks.
The compiler output is a tree of runtime.Module
. DSO-exportable means a runtime.Module
in that tree whose type_key
is c
or llvm
. TVM links directly against LLVM and invokes the LLVM APIs to generate code.
When you call export_library
, TVM traverses the tree of runtime.Module
. When it encounters one with type_key
of llvm
, it uses LLVM APIs to produce binary .o
for the targeted platform, then passes all such encountered modules to the system linker to produce a .so
.
Hi @areusch ,
Thanks a lot. Your reply makes it clear.