search for: addmoduleset

...LayerT, OptimizeFunction> OptimizeLayer; This worked fine with LLVM 4, but causes a problem in LLVM 5. It looks like the issue is that IRTransformLayer::addModule returns an Expected<ModuleT>, whereas GlobalMappingLayer returns just a ModuleHandleT. However, in LLVM 4, IRTransformLayer::addModuleSet returned a ModuleSetT and GlobalMappingLayer::addModuleSet also returned a ModuleSetHandleT, so the types matched up. In LLVM 5, the CompileOnDemandLayer was changed to return an Expected<ModuleHandleT>, but not GlobalMappingLayer. Does that explanation seem correct, or am I missing somethi...

...izeLayer; > > > > This worked fine with LLVM 4, but causes a problem in LLVM 5. It looks > like the issue is that IRTransformLayer::addModule returns an > Expected<ModuleT>, whereas GlobalMappingLayer returns just a > ModuleHandleT. However, in LLVM 4, IRTransformLayer::addModuleSet returned > a ModuleSetT and GlobalMappingLayer::addModuleSet also returned a > ModuleSetHandleT, so the types matched up. In LLVM 5, the > CompileOnDemandLayer was changed to return an Expected<ModuleHandleT>, but > not GlobalMappingLayer. > > > > Does that explanatio...

...improve performance too. > Option (2) would work, but there's no advantage vs option (3). > > So I recommend option 3. :) > > If you're using MCJIT you can override the findSymbol method on the > MemoryManager. If you're using ORC you can pass a custom resolver to > addModuleSet. > > Cheers, > Lang. > > > On Wed, May 11, 2016 at 6:47 AM, Paweł Bylica <chfast at gmail.com> wrote: > >> Hi LLVM, Lang. >> >> I'm looking for a advice here. And I truly understand very little what >> the relocations are and how they work. &gt...

Hello everyone A previous thread about OrcJIT brought up bug reports on Bugzilla. A quick search gives 20+ results: https://bugs.llvm.org/buglist.cgi?component=OrcJIT&list_id=162232&query_format=advanced&resolution=--- While some of them are obviously outdated (addModuleSet API cleanup [1]), others may actually be relevant again (Small code model? [2]). If you reported one of them, please take the time (some day) and review from today's perspective. Are there recommendations regarding Bugzilla reports from other parts of LLVM? Best practices that worked out well?...

...> > A previous thread about OrcJIT brought up bug reports on Bugzilla. A > quick search gives 20+ results: > > https://bugs.llvm.org/buglist.cgi?component=OrcJIT&list_id=162232&query_format=advanced&resolution= > --- > > While some of them are obviously outdated (addModuleSet API cleanup > [1]), others may actually be relevant again (Small code model? [2]). If > you reported one of them, please take the time (some day) and review > from today's perspective. > > Are there recommendations regarding Bugzilla reports from other parts of > LLVM? Best pr...

...two rough categories: Layers and Utilities. Layers are classes that implement a small common interface that makes them easy to compose: class SomeLayer { private: // Implementation details public: // Implementation details typedef ??? Handle; template <typename ModuleSet> Handle addModuleSet(ModuleSet&& Ms); void removeModuleSet(Handle H); uint64_t getSymbolAddress(StringRef Name, bool ExportedSymbolsOnly); uint64_t lookupSymbolAddressIn(Handle H, StringRef Name, bool ExportedSymbolsOnly); }; Layers are usually designed to sit one-on-top-of-another, with each doing so...

Hi LLVM, Lang. I'm looking for a advice here. And I truly understand very little what the relocations are and how they work. The problem I want to solve is the case where a jitted code has to call back the host application to query additional data. I can think of 3 possible solutions: 1. Use built-in relocation resolver (in default memory manager?) and allow the JIT to find the

...hat implement a > small common interface that makes them easy to compose: > > class SomeLayer { > private: > Â // Implementation details > public: > Â // Implementation details > > Â typedef ??? Handle; > > Â template <typename ModuleSet> > Â Handle addModuleSet(ModuleSet&& Ms); > > Â void removeModuleSet(Handle H); > > Â uint64_t getSymbolAddress(StringRef Name, bool ExportedSymbolsOnly); > > Â uint64_t lookupSymbolAddressIn(Handle H, StringRef Name, bool > ExportedSymbolsOnly); > }; > > Layers are usually desi...

...return llvm::RuntimeDyld::SymbolInfo(Addr, llvm::JITSymbolFlags::Exported); return llvm::RuntimeDyld::SymbolInfo(nullptr); }, // Dylib lookup functor [&](const std::string &name) { return nullptr; } ); Compilelayer.addModuleSet (singletonSet(std::move(M)), llvm::make_unique<llvm::SectionMemoryManager>(), std::move(Resolver)); } else { // MCJIT std::string engine_errors; llvm::EngineBuilder engine_builder (std::move(M));...

...ions weren't something I had in mind when I designed Orc, so they raise some interesting design questions which I don't have good answers to yet. (E.g. The interface for the Orc layer concept assumes that there's a RuntimeDyld instance embedded at the bottom of the stack. That's why addModuleSet takes a MemoryManager and SymbolResolver. If there's no RuntimeDyld instance at the bottom of the stack, it's not obvious that the interface should require those). For now I recommend just creating a local copy of the ObjectLinkingLayer and removing the call to resolveRelocations. I'll...

...ect advanced users will want to compose their stacks directly, while beginners would take some common configuration off the shelf. Once these patches are in tree I'm planning to add a basic lazy-jitting stack for Kaleidoscope that beginners could use as a starting point. (3) > Q. Why "addModuleSet" rather than "addModule"? > A. Allowing multiple modules to be passed around together allows layers > lower in the stack to perform interesting optimizations. E.g. direct calls > between objects that are allocated sufficiently close in memory. To add a > single Module you...

...yld::SymbolInfo(Addr, llvm::JITSymbolFlags::Exported); > return llvm::RuntimeDyld::SymbolInfo(nullptr); > }, > // Dylib lookup functor > [&](const std::string &name) { return nullptr; } > ); > Compilelayer.addModuleSet (singletonSet(std::move(M)), > llvm::make_unique<llvm::SectionMemoryManager>(), > std::move(Resolver)); > } else { > // MCJIT > std::string engine_errors; > llvm::EngineBuilder...

...// Build a singleton module set to hold our module. std::vector<std::unique_ptr<Module>> Ms; Ms.push_back(std::move(M)); // Add the set to the JIT with the resolver we created above and a newly // created SectionMemoryManager. return CompileLayer.addModuleSet(std::move(Ms), make_unique<SectionMemoryManager>(), std::move(Resolver)); } JITSymbol findSymbol(const std::string Name) { std::string MangledName; raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWi...

Yes, I’m handling all internal and external relocations manually in NotifyLoadedFtor and I already verified that I get the behavior I need if I comment out the call to resolveRelocations. I would like to reuse ObjectLinkingLayer::addObjectSet (which eventually calls RuntimeDyld::loadObject), which has the right calls to the memory manager and also RuntimeDyld::registerEHFrames. I understand that

...std::vector<std::unique_ptr<Module>> Ms; >> Ms.push_back(std::move(M)); >> >> // Add the set to the JIT with the resolver we created above and >> a newly >> // created SectionMemoryManager. >> return CompileLayer.addModuleSet(std::move(Ms), >> make_unique<SectionMemoryMana >> ger>(), >> std::move(Resolver)); >> } >> >> JITSymbol findSymbol(const std::string Name) { >> std::str...

...vm::JITSymbolFlags::Exported); >> return llvm::RuntimeDyld::SymbolInfo(nullptr); >> }, >> // Dylib lookup functor >> [&](const std::string &name) { return nullptr; } >> ); >> Compilelayer.addModuleSet (singletonSet(std::move(M)), >> >> llvm::make_unique<llvm::SectionMemoryManager>(), >> std::move(Resolver)); >> } else { >> // MCJIT >> std::string engine_errors; >> llvm::EngineBuilder e...

Tried that, still didn't work. Then I tried making a direct API call, GetProcAddress(GetModuleHandle(0),"foo") And this works if and only if __declspec(dllexport) is supplied. So it looks like we were both right. On Sat, Apr 2, 2016 at 9:29 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Have you tried to add dllexport? > > On Sat, Apr 2, 2016 at 4:23 PM

...gt;> Ms; >>>> Ms.push_back(std::move(M)); >>>> >>>> // Add the set to the JIT with the resolver we created above >>>> and a newly >>>> // created SectionMemoryManager. >>>> return CompileLayer.addModuleSet(std::move(Ms), >>>> make_unique<SectionMemoryMana >>>> ger>(), >>>> std::move(Resolver)); >>>> } >>>> >>>> JITSymbol findSymbol(con...

Hi, I think ExecutionEngine 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

...vm::JITSymbolFlags::Exported); >> return llvm::RuntimeDyld::SymbolInfo(nullptr); >> }, >> // Dylib lookup functor >> [&](const std::string &name) { return nullptr; } >> ); >> Compilelayer.addModuleSet (singletonSet(std::move(M)), >> llvm::make_unique<llvm::SectionMemoryManager>(), >> std::move(Resolver)); >> } else { >> // MCJIT >> std::string engine_errors; >>...