search for: setmcjitmemorymanager

...d::unique_ptr<llvm::RTDyldMemoryManager> MemMgr(new llvm::SectionMemoryManager()); std::string err; llvm::EngineBuilder factory(std::move(Mod)); factory.setErrorStr(&err); factory.setEngineKind(llvm::EngineKind::JIT); factory.setTargetOptions(Opts); factory.setMCJITMemoryManager(std::move(MemMgr)); llvm::ExecutionEngine* EE = factory.create(); llvm::sys::DynamicLibrary::AddSymbol("_Z4testv", reinterpret_cast<void*>(test)); EE->finalizeObject(); void* poi = EE->getPointerToFunction(f); void (*exec)(void*) = reinterpret_ca...

Thanks! Currently using MCJIT. But migration to ORC is on my TODO list. - Paweł On Thu, May 12, 2016 at 8:30 PM Lang Hames <lhames at gmail.com> wrote: > Hi Pawel, > > Option (1) and (3) are very similar, but using custom resolution (option > 3) guarantees that JIT'd code can't accidentally end up depending on > functions in your JIT that you didn't mean to

There is no documentation I know of. Rough sketch: 1) Create a subclass of SectionMemoryManager 2) Create an instance of this class and add it the EngineBuilder via setMCJITMemoryManager (Make sure everything runs without changes) 3) Override the getSymbolAddress method, have your implementation call the base classes impl (Make sure everything runs without changes) 4) Add handling to map name->address for any custom functions you want. On 03/28/2016 09:18 PM, Russell Wallace...

Hi, What other options do I have to reduce JIT time for large amount of code? - setting optimization level to none helps a lot - enabling FastISel doesn't seem to help much Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160812/f05d51fb/attachment.html>

...uot;es :) On Tue, Mar 29, 2016 at 6:51 PM Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > There is no documentation I know of. Rough sketch: > 1) Create a subclass of SectionMemoryManager > 2) Create an instance of this class and add it the EngineBuilder via > setMCJITMemoryManager > (Make sure everything runs without changes) > 3) Override the getSymbolAddress method, have your implementation call the > base classes impl > (Make sure everything runs without changes) > 4) Add handling to map name->address for any custom functions you want. > > > &gt...

True, I care more about how fast the code runs than how long it takes to compile it. So if the symbolic approach enables better code generation, that is a very significant advantage from my perspective. Is there any example code or documentation you can point to for details about how to implement the symbolic approach? Is it similar to any of the versions of Kaleidoscope or any other extant

..., 2016 at 6:51 PM Philip Reames via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> There is no documentation I know of. Rough sketch: >> 1) Create a subclass of SectionMemoryManager >> 2) Create an instance of this class and add it the EngineBuilder via >> setMCJITMemoryManager >> (Make sure everything runs without changes) >> 3) Override the getSymbolAddress method, have your implementation call >> the base classes impl >> (Make sure everything runs without changes) >> 4) Add handling to map name->address for any custom functions you want...

...ev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > There is no documentation I know of. Rough sketch: > 1) Create a subclass of SectionMemoryManager > 2) Create an instance of this class and add it the EngineBuilder > via setMCJITMemoryManager > (Make sure everything runs without changes) > 3) Override the getSymbolAddress method, have your implementation > call the base classes impl > (Make sure everything runs without changes) > 4) Add handling to map name->address for any custom functions you >...

...ring &Name) { > return (uint64_t)dlsym(SELF_HANDLE, Name.c_str() + 1); > /* + 1 with MacOS, + 0 with Linux */ > } > } > > which is called by MCJIT to resolve external symbols when the jited > module is loaded in memory (you have to use > EngineBuilder.setMCJITMemoryManager). > > If, like me, you want to also inline functions from jited modules, > it's a little bit more tricky because the llvm::Function* original = > runtimeModule->getFunction(callee->getName()); is not enough. I have > defined my own symbol table (a hash map) that associates...

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