search for: getfunctionaddress

...Sel and disabled optimizations. Jit time is still too slow for my purpose (I do have a lot of code to Jit). http://llvm.org/docs/ProgrammersManual.html#threads-and-the-jit states that we can invoke ExecutionEngine::getPointerToFunction() concurrently. This function was replaced by ExecutionEngine::getFunctionAddress(). Is this function also thread safe? I want to speed up codegen by invoking parallel calls to getfunctionaddress(). Currently due the the large amount of code that has to be Jitted, the getfunctionaddress() takes around 40% of my load time. What is meant with "he user must still ensure tha...

In MCJIT, the old JIT functions are deprecated in favor of getFunctionAddress. Code like: llvm::Function *F = M->getFunction(FuncName); void *FN = EE->getPointerToFunction(F); should be rewritten as uint64_t FN = EE->getFunctionAddress(FuncName); While functionally identical, in case the correct module is known the new version will be much slower, linear w...

So I've made code to invoke the getfunctionaddress() in parallel. I did verify that the code was good, by substituting getfunctionaddress() with a bunch bogus computations. It seems that the code with getfunctionaddress() is being serialized. Is there a giant lock somewhere per executionengine? I have one execution engine that holds all the module...

...be useful. See my other comments on this topic in the other reply. > > -Andy > > > From: Yaron Keren [mailto:yaron.keren at gmail.com] > Sent: Saturday, October 19, 2013 3:17 PM > To: Kaylor, Andrew; <llvmdev at cs.uiuc.edu> > Subject: An enhancement for MCJIT::getFunctionAddress > > In MCJIT, the old JIT functions are deprecated in favor of getFunctionAddress. > Code like: > > llvm::Function *F = M->getFunction(FuncName); > void *FN = EE->getPointerToFunction(F); > > should be rewritten as > > uint64_t FN = EE->getFunct...

...ut some form of what you are suggesting may be useful. See my other comments on this topic in the other reply. -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Saturday, October 19, 2013 3:17 PM To: Kaylor, Andrew; <llvmdev at cs.uiuc.edu> Subject: An enhancement for MCJIT::getFunctionAddress In MCJIT, the old JIT functions are deprecated in favor of getFunctionAddress. Code like: llvm::Function *F = M->getFunction(FuncName); void *FN = EE->getPointerToFunction(F); should be rewritten as uint64_t FN = EE->getFunctionAddress(FuncName); While functionally identical, in...

...some information about the things that didn't match and optimize the next search. -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Monday, October 21, 2013 4:39 PM To: Kaylor, Andrew; Yaron Keren Cc: <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] An enhancement for MCJIT::getFunctionAddress The search is linear? If that's really true, we should fix that. On Oct 21, 2013, at 10:14 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: I should have read this before sending my previous reply. :-) I'm not a big fan of default pa...

...ve a lot of code to Jit). > > http://llvm.org/docs/ProgrammersManual.html#threads-and-the-jit <http://llvm.org/docs/ProgrammersManual.html#threads-and-the-jit> states that we can invoke ExecutionEngine::getPointerToFunction() concurrently. This function was replaced by ExecutionEngine::getFunctionAddress(). Is this function also thread safe? > > I want to speed up codegen by invoking parallel calls to getfunctionaddress(). Currently due the the large amount of code that has to be Jitted, the getfunctionaddress() takes around 40% of my load time. > > What is meant with "he user m...

...didn’t match and optimize the next search. > > -Andy > > From: Jim Grosbach [mailto:grosbach at apple.com] > Sent: Monday, October 21, 2013 4:39 PM > To: Kaylor, Andrew; Yaron Keren > Cc: <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] An enhancement for MCJIT::getFunctionAddress > > The search is linear? If that’s really true, we should fix that. > > On Oct 21, 2013, at 10:14 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > > > I should have read this before sending my previous reply. :-) > > I’m not a big fan of default par...

...**** > > -Andy**** > > *From:* Jim Grosbach [mailto:grosbach at apple.com <grosbach at apple.com>] > *Sent:* Monday, October 21, 2013 4:39 PM > *To:* Kaylor, Andrew; Yaron Keren > *Cc:* <llvmdev at cs.uiuc.edu> > *Subject:* Re: [LLVMdev] An enhancement for MCJIT::getFunctionAddress**** > ** ** > The search is linear? If that’s really true, we should fix that.**** > ** ** > On Oct 21, 2013, at 10:14 AM, Kaylor, Andrew <andrew.kaylor at intel.com> > wrote:**** > > > **** > I should have read this before sending my previous reply. :-)**** > *...

Hi everyone, In llvm 4.0 the MCJIT::getFunctionAddress function return 0 (a null address) when the symbol is not found : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name,...

...as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and wish to have access to some methods not available from ExecutionEngine. E.g. I would like to use getSymbolAddress() instead of getFunctionAddress() sometimes as getFunctionAddress() do some additional work what I'm sure has be done already. May...

...t can happen that the same piece of code is sent to the service many times. I would like to cache the results (keep generated machine code alive) and do just the execution step. But I'm having problems with that. My first attempt was to cache ExecutionEngine instance and function address (from getFunctionAddress() method). Executing cached function second time crashes the process. I noticed that doing getFunctionAddress() each time helps a bit. There is no crash but results produced by executed function are incorrect and there are probably some memory access violations going on. Using the same function n...

...opy(B.getBuffer(), B.getBufferIdentifier()); } else return nullptr; }; } When I generate the code for the first time, everything works fine. the objects in CachedObjs are dumped to disk and reloaded for the next run. However with the next run (thus using the cached objects) the executionengine->getFunctionAddress() *sometimes *returns nullptr for a function that exists in the cache. I've traced into the cache call, and could see that my getObject() returned the right object. The object is loaded and no error was reported by ( MCJIT::generateCodeForModule(Module *M)): // Load the object into the dynam...

...rpreter and >> MCJIT is almost useless in the current form. There are separated methods in >> ExecutionEngine for similar or the same features provided by Interpreter >> and MCJIT, i.e. to get a pointer to function you should call >> getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. >> >> Personally, I'm using MCJIT and wish to have access to some methods not >> available from ExecutionEngine. E.g. I would like to use getSymbolAddress() >> instead of getFunctionAddress() sometimes as getFunctionAddress() do some >> additional work...

...MCJIT::emitObject(this=0x0000000106fa69a0, M=0x0000000106fe6f30) + 236 at MCJIT.cpp:131 frame #19: 0x0000000100eeb2d3 libjvm.dylib`llvm::MCJIT::generateCodeForModule(this=0x0000000106fa69a0, M=0x0000000106fe6f30) + 323 at MCJIT.cpp:169 frame #20: 0x0000000100eec022 libjvm.dylib`llvm::MCJIT::getFunctionAddress(std::string const&) [inlined] llvm::MCJIT::getSymbolAddress(this=0x0000000106fa69a0, CheckFunctionsOnly=true) + 58 at MCJIT.cpp:279 frame #21: 0x0000000100eebfe8 libjvm.dylib`llvm::MCJIT::getFunctionAddress(this=0x0000000106fa69a0, Name=0x00007fff5fbfe7b0) + 40 at MCJIT.cpp:295 ... So, I d...

...0000106fa69a0, > M=0x0000000106fe6f30) + 236 at MCJIT.cpp:131 > frame #19: 0x0000000100eeb2d3 > libjvm.dylib`llvm::MCJIT::generateCodeForModule(this=0x0000000106fa69a0, > M=0x0000000106fe6f30) + 323 at MCJIT.cpp:169 > frame #20: 0x0000000100eec022 > libjvm.dylib`llvm::MCJIT::getFunctionAddress(std::string const&) > [inlined] llvm::MCJIT::getSymbolAddress(this=0x0000000106fa69a0, > CheckFunctionsOnly=true) + 58 at MCJIT.cpp:279 > frame #21: 0x0000000100eebfe8 > libjvm.dylib`llvm::MCJIT::getFunctionAddress(this=0x0000000106fa69a0, > Name=0x00007fff5fbfe7b0) + 40 at MC...

...0000106fa69a0, > M=0x0000000106fe6f30) + 236 at MCJIT.cpp:131 > frame #19: 0x0000000100eeb2d3 > libjvm.dylib`llvm::MCJIT::generateCodeForModule(this=0x0000000106fa69a0, > M=0x0000000106fe6f30) + 323 at MCJIT.cpp:169 > frame #20: 0x0000000100eec022 > libjvm.dylib`llvm::MCJIT::getFunctionAddress(std::string const&) > [inlined] llvm::MCJIT::getSymbolAddress(this=0x0000000106fa69a0, > CheckFunctionsOnly=true) + 58 at MCJIT.cpp:279 > frame #21: 0x0000000100eebfe8 > libjvm.dylib`llvm::MCJIT::getFunctionAddress(this=0x0000000106fa69a0, > Name=0x00007fff5fbfe7b0) + 40 at MC...

...bitcode (clang -S -emit-llvm jit.cpp) // and is read into Module M here Module *M = ... ExecutionEngine *ee = ... myglobal = 42; ee->addGlobalMapping(M->getGlobalVariable("myglobal"), (void*)&myglobal); ee->finalizeObject(); void(*fptr)() = (void(*)())ee->getFunctionAddress("printMyGlobal"); fptr(); printMyGlobal(); } // end file jit.cpp I compile this file (jit.cpp) into bitcode which I then load int M. M also contains a global variable called myglobal. I want to "map" the myglobal variable in M to the global variable in the running program...

...///////////////////////////////////////////////////////////// // Define the input/output data type in LLVM function typedef std::vector<int64_t> VecInt; auto function = reinterpret_cast<VecInt (*)(VecInt , VecInt, VecInt, VecInt, VecInt, VecInt, VecInt, VecInt)>(TheExecutionEngine->getFunctionAddress(TheFunction->getName().str())); VecInt result = function(functionCallArgs[0],functionCallArgs[1],functionCallArgs[2],functionCallArgs[3], functionCallArgs[4],functionCallArgs[5],functionCallArgs[6],functionCallArgs[7]); std::cout<<"result size "<< result.size()<<&qu...

Oops, missed initializing some stuff. Added: LLVMLinkInMCJIT(); LLVMInitializeNativeTarget(); LLVMInitializeNativeAsmPrinter(); LLVMInitializeNativeAsmParser(); Now it crashes in LLVMGetFunctionAddress(). Hmm. On Wed, Mar 8, 2017 at 5:14 PM, Toshiyasu Morita <toshi at tensyr.com> wrote: > Made it a bit further. Here's the current code: > > void llvm_load_IR_library(char *path) > { > char *error; > LLVMExecutionEngineRef engine; > object0_...