On Jan 8, 2013, at 13:55 , "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:> You need to include 'llvm/ExecutionEngine/JIT.h' (or 'llvm/ExecutionEngine/JIT.h' if you want that engine) from your main file. Including that file forces the JIT static constructor to be linked into your executable. Without it, the JIT static constructor gets optimized out and you get the result you're seeing.Wow, how obscure! Thank you; I never would've figured that out. Why is it done that way? That seems…quite horrible, actually. Why not just instantiate the JIT on demand as part of instantiating the Engine? Thanks again. It works now. Thank you. Thank you. -- Rick
Rick Mann <rmann at latencyzero.com> writes:> On Jan 8, 2013, at 13:55 , "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > >> You need to include 'llvm/ExecutionEngine/JIT.h' (or >> llvm/ExecutionEngine/JIT.h' if you want that engine) from your main >> file. Including that file forces the JIT static constructor to be >> linked into your executable. Without it, the JIT static constructor >> gets optimized out and you get the result you're seeing. > > Wow, how obscure! Thank you; I never would've figured that out. > > Why is it done that way? That seems…quite horrible, actually. Why not > just instantiate the JIT on demand as part of instantiating the > Engine?I guess that instantiating the JIT on that way would force the clients to link with that feature (which exists only on selected platforms.) If the user wants the interpreter, why should he be forced to include the JIT on the final executable? And vice-versa: if you are interested only on the JIT, why should your executable carry the weight of the interpreter?
I agree that it is quite horrible. I've been bitten by the same problem you had and was equally mystified. I'm not entirely sure why it was done that way. It's been like that for as long as I've been working with LLVM. I'd guess that it had something to do with being able to build and link without the JIT enabled. I know there's a specific LLVM coding standard against this sort of construct. We just haven't gotten around to cleaning this up yet. -Andy -----Original Message----- From: Rick Mann [mailto:rmann at latencyzero.com] Sent: Tuesday, January 08, 2013 8:13 PM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] ExecutionEngine always comes back NULL On Jan 8, 2013, at 13:55 , "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:> You need to include 'llvm/ExecutionEngine/JIT.h' (or 'llvm/ExecutionEngine/JIT.h' if you want that engine) from your main file. Including that file forces the JIT static constructor to be linked into your executable. Without it, the JIT static constructor gets optimized out and you get the result you're seeing.Wow, how obscure! Thank you; I never would've figured that out. Why is it done that way? That seems...quite horrible, actually. Why not just instantiate the JIT on demand as part of instantiating the Engine? Thanks again. It works now. Thank you. Thank you. -- Rick
On Jan 9, 2013, at 9:09 , Óscar Fuentes <ofv at wanadoo.es> wrote:> I guess that instantiating the JIT on that way would force the clients > to link with that feature (which exists only on selected platforms.) If > the user wants the interpreter, why should he be forced to include the > JIT on the final executable? And vice-versa: if you are interested only > on the JIT, why should your executable carry the weight of the > interpreter?I can think of at least a couple of ways to handle that so that it's explicit: either instantiate a sub-class of ExecutionEngine that uses JIT, or instantiate a JIT explicitly to pass to ExecutionEngine. Or calling ExecutionEngine::createJIT() should cause a link-time error (but not if it's not called). -- Rick