[LLVMdev] MCJIT versus getLazyBitcodeModule?

[Kaylor, Andrew]

Actually, I think linking just pulls referenced functions and variables into your module, so they could be inlined in that case.

On the other hand, if I'm correct about how Module linking works, you may run into problems if multiple Modules which link in the same function are passed to the same instance of MCJIT.  There ought to be a way around this whereby you could first ask MCJIT if it has a symbol and if it does link against that (which wouldn't allow inlining) and it not link against the big bitcode Module.  Unfortunately I think you'd have to build your own support for that.

Also, I should say that there is every possibility that I am misunderstanding how Module linking works.  I haven't done anything with that in a while and I think that part of the code has been updated since then.

-Andy

-----Original Message-----
From: Larry Gritz [mailto:lg at larrygritz.com] 
Sent: Tuesday, January 21, 2014 12:52 PM
To: Kaylor, Andrew
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] MCJIT versus getLazyBitcodeModule?

Thanks for the pointers.

Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions?

	-- lg


On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:

> I would say that the incompatibility is by design.  Not that anyone specifically wanted the incompatibility, but rather it's a known artifact of the MCJIT design.
> 
> You can find an example of MCJIT's object caching here: http://blog.llvm.org/2013/08/object-caching-with-kaleidoscope.html
> 
> The two blog entries before that may also be of use to you: http://blog.llvm.org/2013_07_01_archive.html
> 
> I don't where you can find an example of the Module linking I described, but I think llvm::Linker is the class to look at.
> 
> -Andy
> 

--
Larry Gritz
lg at larrygritz.com