mbarrett97 commented on issue #4847: Return empty CSourceModule when no lowered_funcs exists in Relay mod URL: https://github.com/apache/incubator-tvm/pull/4847#issuecomment-585449674 I should probably explain my 'test case' :) Apologies if you know this all already. I'm using the external codegen feature which is relatively new. Essentially it allows you to take parts of the Relay graph and run them through a non-TVM compiler. In some cases, we take the entire Relay graph and put it through one of these external compilers resulting in the case where there are no lowered TVM functions. What does get produced though is 'external' runtime modules which correspond to the outputs from these external compilers. You can see this happening in the BuildRelay function. We call 'GetExternalModules' to get those modules that have been produced by external compilers. But to be able to compile these modules into a shared library, we need a 'host' TVM module. This host module then 'imports' in all the external modules, as you can see here: https://github.com/apache/incubator-tvm/blob/a5661611472c8e92b20bbe4d074333b8183f2878/src/relay/backend/build_module.cc#L458 However, if there is no host TVM module (which will happen when there are no lowered funcs), then you can't import the external modules into a host module and accordingly we fail to compile the result to a shared library. So this fix is very helpful by making sure that host module always gets created, even if it's empty, so we can always compile to a shared library. Now addressing your questions. For 1, yes I think we just remove this branch entirely and have it always import the external modules. For 2, I hit the assert when trying to call export_library on the 'lib' output of the build function. I believe SaveToFile is called when doing this export, in particular this line: https://github.com/apache/incubator-tvm/blob/79cfab00d1a5ae55b3324dae803d5e1389e12bbe/python/tvm/runtime/module.py#L302 I did try just commenting out the assert and it seems to work. However, I then ran into a new problem... Because what you produce is ostensibly a 'c source' file (even if it's empty), all the external modules are also exported as c files. This results in having to do a proper compile when you try and merge all the modules together to produce a shared library. If one of your external modules happens to be a binary artifact that's 150MB (my case), this compile uses an incredible amount of RAM and takes a long time to complete. I didn't get this problem with your first solution as it used an LLVMModule (I think?) which results in the external modules becoming object files so all you need to do is link, not perform a full compilation. Sorry for the wall of text, if you have any further questions I'll happily answer them. I realise I may not have perfectly explained everything here :)
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
