search for: objectlay

Hi all, I am having hard time figuring out how I should use the API for JIT in LLVM 6. In LLVM 3.9 I am used to adding all objects at once and emitAndFinalizing them all: handle = objectLayer.addObjectSet(objectFiles, memoryManager, resolver); objectLayer.emitAndFinalize(handle); In LLVM 6.0 the objects are added one by one: auto handle = objectLayer.addObject(objectFile, resolver).get(); objectLayer.emitAndFinalize(handle); The problem is that emitAndFinalize in this case works fo...

...cLazyJIT.h b/tools/lli/OrcLazyJIT.h index 47a2acc4d7e..41a7c99413b 100644 --- a/tools/lli/OrcLazyJIT.h +++ b/tools/lli/OrcLazyJIT.h @@ -62,7 +62,11 @@ public:               bool InlineStubs)        : TM(std::move(TM)), DL(this->TM->createDataLayout()),         CCMgr(std::move(CCMgr)), -       ObjectLayer([]() { return std::make_shared<SectionMemoryManager>(); }), +       ObjectLayer([]() { return std::make_shared<SectionMemoryManager>(); }, +              [this](llvm::orc::RTDyldObjectLinkingLayerBase::ObjHandleT, +                     const llvm::orc::RTDyldObjectLinkingLayerBase::Ob...

I'm trying to use PerfJITEventListener with llvm::orc::LLJITBuilder: 1. perf record -o /tmp/perf.data -- <my_binary_with_event_listener> 2. perf inject -j -v -i /tmp/perf.data -o /tmp/perf.data.jit *jit marker found: ~.debug/jit/llvm-IR-jit-20200417-3c2242/jit-149849.dump* *injecting: ~/.debug/jit/llvm-IR-jit-20200417-3c2242/jit-149849.dump* *write ELF image

...depends on the IR code generated from the source code. Here's how I created the JIT: llvm::InitializeNativeTarget(); llvm::InitializeNativeTargetAsmPrinter(); llvm::InitializeNativeTargetAsmParser(); // create jit llvm::orc::ExecutionSession ES; llvm::orc::RTDyldObjectLinkingLayer ObjectLayer(ES, []() { return std::make_unique<llvm::SectionMemoryManager>(); }); auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost(); auto DL = JTMB->getDefaultDataLayoutForTarget(); llvm::orc::IRCompileLayer CompileLayer(ES, ObjectLa...

...                                      >                                                                       >                                       >     return Obj; >   } > >   std::unique_ptr<TargetMachine> TM; >   const DataLayout DL; >   RTDyldObjectLinkingLayer ObjectLayer; >   ObjectTransformLayer<decltype(ObjectLayer), >                        decltype(&KaleidoscopeJIT::dumpObject)> > DumpObjectsLayer; >   IRCompileLayer<decltype(DumpObjectsLayer), SimpleCompiler> CompileLayer; > > public: >   using ModuleHandle = decltype(Com...

...Target/TargetMachine.h"#include<algorithm>#include<memory>#include<string>#include<vector>usingnamespacellvm;usingnamespacellvm::orc;namespacetl {namespacecontrib {classGenericJIT{private:std::unique_ptr<TargetMachine>TM;constDataLayoutDL;RTDyldObjectLinkingLayerObjectLayer;IRCompileLayer<decltype(ObjectLayer),SimpleCompiler>CompileLayer;public:usingModuleHandle=decltype(CompileLayer)::ModuleSetHandleT;GenericJIT():TM(EngineBuilder().selectTarget()),DL(TM->createDataLayout()),ObjectLayer([](){returnstd::make_shared<SectionMemoryManager>();}),CompileLa...

Trying to put together a simple test JIT compiler, using ORC which as I understand it will be the supported API going forward, I noticed that in the first chapter of the updated Kaleidoscope tutorial, there is sample code that starts like this: ExecutionSession ES; RTDyldObjectLinkingLayer ObjectLayer; IRCompileLayer CompileLayer; DataLayout DL; MangleAndInterner Mangle; ThreadSafeContext Ctx; But in https://llvm.org/devmtg/2016-11/Slides/Hames-ORC.pdf there is sample code that looks like this: ObjectLinkingLayer LinkLayer; SimpleCompiler Compiler(TargetMachine()); IRCompileLayer<…> C...

Hi all, I am using LLVM for JIT use-case and compile functions on the fly. I want to "free" the modules after some time and reclaim any memory associated with it. I am using the SimpleORC API <https://llvm.org/docs/tutorial/BuildingAJIT1.html> now. Is there an API to "free" all the memory associated with the module? I use one "compiler" instance (think similar

...ugging I think I understand what goes wrong. Here is my hypothesis: JIT allocates and maps some memory for the execution. Some function X at address 0xdeadbeef is part of this memory. JIT calls a code that passes the X to atexit. JIT deallocates and unmaps the memory used for execution (either via objectLayer.removeObjectSet or by calling JIT's destructors) atexit (cxa_finalize_ranges) calls the X at 0xdeadbeef which does not belong to 'us' anymore, which leads to the crash. Given that my assumption is correct what can we do about this? Is there anything that can be done to cover this cas...

...ease_40/examples/Kaleidoscope/BuildingAJIT/Chapter1/KaleidoscopeJIT.h * This is from the same revision of LLVM I am using (the release_40 branch as of 4/8/2017) */ class KaleidoscopeJIT { private: std::unique_ptr<TargetMachine> TM; const DataLayout DL; ObjectLinkingLayer<> ObjectLayer; IRCompileLayer<decltype(ObjectLayer)> CompileLayer; public: typedef decltype(CompileLayer)::ModuleSetHandleT ModuleHandle; KaleidoscopeJIT() : TM(EngineBuilder().selectTarget()), DL(TM->createDataLayout()), CompileLayer(ObjectLayer, SimpleCompiler...

Dear LLVM-Developers and Vinod Grover, we are trying to extend the cling C++ interpreter (https://github.com/root-project/cling) with CUDA functionality for Nvidia GPUs. I already developed a prototype based on OrcJIT and am seeking for feedback. I am currently a stuck with a runtime issue, on which my interpreter prototype fails to execute kernels with a CUDA runtime error. === How to use the

...t;> * This is from the same revision of LLVM I am using (the release_40 >> branch as of 4/8/2017) >> */ >> class KaleidoscopeJIT { >> private: >> std::unique_ptr<TargetMachine> TM; >> const DataLayout DL; >> ObjectLinkingLayer<> ObjectLayer; >> IRCompileLayer<decltype(ObjectLayer)> CompileLayer; >> >> public: >> typedef decltype(CompileLayer)::ModuleSetHandleT ModuleHandle; >> >> KaleidoscopeJIT() >> : TM(EngineBuilder().selectTarget()), >> DL(TM->creat...

...ing (the release_40 >>>> branch as of 4/8/2017) >>>> */ >>>> class KaleidoscopeJIT { >>>> private: >>>> std::unique_ptr<TargetMachine> TM; >>>> const DataLayout DL; >>>> ObjectLinkingLayer<> ObjectLayer; >>>> IRCompileLayer<decltype(ObjectLayer)> CompileLayer; >>>> >>>> public: >>>> typedef decltype(CompileLayer)::ModuleSetHandleT ModuleHandle; >>>> >>>> KaleidoscopeJIT() >>>> : TM(E...

...M +0100, Alex Denisov via llvm-dev wrote: >> JIT allocates and maps some memory for the execution. Some function X at address 0xdeadbeef is part of this memory. >> JIT calls a code that passes the X to atexit. >> JIT deallocates and unmaps the memory used for execution (either via objectLayer.removeObjectSet or by calling JIT's destructors) >> atexit (cxa_finalize_ranges) calls the X at 0xdeadbeef which does not belong to 'us' anymore, which leads to the crash. > > Sounds plausible. > >> Given that my assumption is correct what can we do about this?...

...you know if there is a way to directly load .obj-Files and resolve the > references with own addresses? Like when somebody used printf in the > generated obj-File, but I replace the address with my own printf? > > You can load precompiled object files by calling addObjectSet on the > ObjectLayer. > > All external symbol references are resolved by the JITSymbolResolver that > is created by createLambdaResolver. In your example the resolution process > is two-step: First the JIT searches its own function definitions to see if > there is a function called "printf" d...

...f 4/8/2017) >>>>>> */ >>>>>> class KaleidoscopeJIT { >>>>>> private: >>>>>> std::unique_ptr<TargetMachine> TM; >>>>>> const DataLayout DL; >>>>>> ObjectLinkingLayer<> ObjectLayer; >>>>>> IRCompileLayer<decltype(ObjectLayer)> CompileLayer; >>>>>> >>>>>> public: >>>>>> typedef decltype(CompileLayer)::ModuleSetHandleT ModuleHandle; >>>>>> >>>>>> Kalei...

...; >> JIT allocates and maps some memory for the execution. Some > function X at address 0xdeadbeef is part of this memory. > >> JIT calls a code that passes the X to atexit. > >> JIT deallocates and unmaps the memory used for execution > (either via objectLayer.removeObjectSet or by calling JIT's > destructors) > >> atexit (cxa_finalize_ranges) calls the X at 0xdeadbeef which > does not belong to 'us' anymore, which leads to the crash. > > > > Sounds plausible. > > > >> Gi...

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

...IT allocates and maps some memory for the execution. Some >> function X at address 0xdeadbeef is part of this memory. >> >> JIT calls a code that passes the X to atexit. >> >> JIT deallocates and unmaps the memory used for execution >> (either via objectLayer.removeObjectSet or by calling JIT's >> destructors) >> >> atexit (cxa_finalize_ranges) calls the X at 0xdeadbeef which >> does not belong to 'us' anymore, which leads to the crash. >> > >> > Sounds plausible. >> &...

...e objects to the server (rather than fully relocated /// bits) allows JIT'd code to be cached on the server side and re-used in /// subsequent JIT sessions. There are a few tests here that illustrate its usage: https://github.com/llvm-mirror/llvm/blob/master/unittests/ExecutionEngine/Orc/RemoteObjectLayerTest.cpp Note that it still uses LegacyJITSymbolResolver, so I guess it may change any time soon. Hope it helps for the time being. Cheers, Stefan Am 05.11.18 um 19:44 schrieb Christian Schafmeister via llvm-dev: > I think I found the answer to #3 and #4. > (a) I overloaded the SectionMem...