search for: simplecompiler

Hi Lang, I'm looking at extending the compilation passes used in the LLILC JIT and it seems like the simplest thing is to make a copy of the SimpleCompiler functor into the LLILC code and then modify it for the phases I want to run. But I was wondering if this was the best approach. Do you expect different clients to create their own compiler functors or do you imagine that SimpleCompiler will be joined by more sophisticated siblings that are more...

Hi devs, hi Lang, I use ORC’s SimpleCompiler to compile modules into object files and it works just great, however I’m having an issue: a module gets changed a bit when I compile it (some transformations/optimizations applied). I tried to set optimization level of a TargetMachine to None, but the module gets changed anyway. The question is:...

...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<…> CompileLayer(LinkLayer, Compiler); Related but significantly different. Which version is now considered correct/preferred? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-de...

...er.h:311: llvm::Error llvm::orc::LegacyCompileOnDemandLayer<BaseLayerT, CompileCallbackMgrT, IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with BaseLayerT = llvm::orc::LegacyIRTransformLayer<llvm::orc::LegacyIRCompileLayer<llvm::orc::LegacyRTDyldObjectLinkingLayer, llvm::orc::SimpleCompiler>, std::function<std::unique_ptr<llvm::Module>(std::unique_ptr<llvm::Module>)> >; CompileCallbackMgrT = llvm::orc::JITCompileCallbackManager; IndirectStubsMgrT = llvm::orc::IndirectStubsManager; llvm::orc::VModuleKey = long unsigned int]: Assertion `I != LogicalDylibs.end() &...

...TargetMachine> TM; >   const DataLayout DL; >   RTDyldObjectLinkingLayer ObjectLayer; >   ObjectTransformLayer<decltype(ObjectLayer), >                        decltype(&KaleidoscopeJIT::dumpObject)> > DumpObjectsLayer; >   IRCompileLayer<decltype(DumpObjectsLayer), SimpleCompiler> CompileLayer; > > public: >   using ModuleHandle = decltype(CompileLayer)::ModuleHandleT; > >   KaleidoscopeJIT() >       : TM(EngineBuilder().selectTarget()), DL(TM->createDataLayout()), >         ObjectLayer([]() { return > std::make_shared<SectionMemoryManager&g...

...+              [this](llvm::orc::RTDyldObjectLinkingLayerBase::ObjHandleT, +                     const llvm::orc::RTDyldObjectLinkingLayerBase::ObjectPtr &obj, +                     const llvm::RuntimeDyld::LoadedObjectInfo &info) { +              }),          CompileLayer(ObjectLayer, orc::SimpleCompiler(*this->TM)),          IRDumpLayer(CompileLayer, createDebugDumper()),          CODLayer(IRDumpLayer, extractSingleFunction, *this->CCMgr, Diagnostic message: error: no matching constructor for initialization of 'ObjLayerT' (aka 'llvm::orc::RTDyldObjectLinkingLayer')         O...

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

...lt;llvm::ExecutionEngine> EE; typedef llvm::orc::ObjectLinkingLayer<> ObjLayerT; typedef llvm::orc::IRCompileLayer<ObjLayerT> CompileLayerT; typedef CompileLayerT::ModuleSetHandleT ModuleHandleT; ObjLayerT Objlayer; CompileLayerT Compilelayer (Objlayer, llvm::orc::SimpleCompiler(*TM)); std::unique_ptr<llvm::Module> M (new llvm::Module("module", Context)); M->setDataLayout (*DL); // Declare stub for external function sqr auto type_float = llvm::Type::getFloatTy (Context); llvm::Type* one_float[] = { type_float }; llvm::FunctionTyp...

Hi, On 2018-07-19 14:57:42 +0200, Frank Tetzel via llvm-dev wrote: > > Have you seen https://reviews.llvm.org/D44892? we are using it in > > Julia to use perf on jitted code. > > No, I did not see this patch before. Thanks a lot for the pointer. > > It seems to be doing exactly what I want. Let's see if I get it working. FWIW, I just merged this. Did you have any

...:orc::LegacyCompileOnDemandLayer<BaseLayerT, CompileCallbackMgrT, >> IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with >> BaseLayerT = llvm::orc::LegacyIRTransformLayer<llvm::orc::LegacyIRCompileLayer<llvm::orc::LegacyRTDyldObjectLinkingLayer, >> llvm::orc::SimpleCompiler>, >> std::function<std::unique_ptr<llvm::Module>(std::unique_ptr<llvm::Module>)> >> >; CompileCallbackMgrT = llvm::orc::JITCompileCallbackManager; >> IndirectStubsMgrT = llvm::orc::IndirectStubsManager; >> llvm::orc::VModuleKey = long unsigned int]: A...

...;#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>();}),CompileLayer(ObjectLayer){llvm::sys::DynamicLibrary::LoadLibraryPe...

...gt; EE; > typedef llvm::orc::ObjectLinkingLayer<> ObjLayerT; > typedef llvm::orc::IRCompileLayer<ObjLayerT> CompileLayerT; > typedef CompileLayerT::ModuleSetHandleT ModuleHandleT; > ObjLayerT Objlayer; > CompileLayerT Compilelayer (Objlayer, llvm::orc::SimpleCompiler(*TM)); > std::unique_ptr<llvm::Module> M (new llvm::Module("module", Context)); > M->setDataLayout (*DL); > > // Declare stub for external function sqr > auto type_float = llvm::Type::getFloatTy (Context); > llvm::Type* one_float[] = { type_...

...> ObjectLayer; IRCompileLayer<decltype(ObjectLayer)> CompileLayer; public: typedef decltype(CompileLayer)::ModuleSetHandleT ModuleHandle; KaleidoscopeJIT() : TM(EngineBuilder().selectTarget()), DL(TM->createDataLayout()), CompileLayer(ObjectLayer, SimpleCompiler(*TM)) { llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); } TargetMachine &getTargetMachine() { return *TM; } ModuleHandle addModule(std::unique_ptr<Module> M) { // Build our symbol resolver: // Lambda 1: Look back into the JIT itself to fin...

...ileLayer; >> >> public: >> typedef decltype(CompileLayer)::ModuleSetHandleT ModuleHandle; >> >> KaleidoscopeJIT() >> : TM(EngineBuilder().selectTarget()), >> DL(TM->createDataLayout()), >> CompileLayer(ObjectLayer, SimpleCompiler(*TM)) { >> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); >> } >> >> TargetMachine &getTargetMachine() { return *TM; } >> >> ModuleHandle addModule(std::unique_ptr<Module> M) { >> // Build our symbol resolv...

...typedef llvm::orc::ObjectLinkingLayer<> ObjLayerT; >> typedef llvm::orc::IRCompileLayer<ObjLayerT> CompileLayerT; >> typedef CompileLayerT::ModuleSetHandleT ModuleHandleT; >> ObjLayerT Objlayer; >> CompileLayerT Compilelayer (Objlayer, llvm::orc::SimpleCompiler(*TM)); >> std::unique_ptr<llvm::Module> M (new llvm::Module("module", Context)); >> M->setDataLayout (*DL); >> >> // Declare stub for external function sqr >> auto type_float = llvm::Type::getFloatTy (Context); >> llvm::Type...

...> typedef decltype(CompileLayer)::ModuleSetHandleT ModuleHandle; >>>> >>>> KaleidoscopeJIT() >>>> : TM(EngineBuilder().selectTarget()), >>>> DL(TM->createDataLayout()), >>>> CompileLayer(ObjectLayer, SimpleCompiler(*TM)) { >>>> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); >>>> } >>>> >>>> TargetMachine &getTargetMachine() { return *TM; } >>>> >>>> ModuleHandle addModule(std::unique_ptr<Module>...

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

...typedef llvm::orc::ObjectLinkingLayer<> ObjLayerT; >> typedef llvm::orc::IRCompileLayer<ObjLayerT> CompileLayerT; >> typedef CompileLayerT::ModuleSetHandleT ModuleHandleT; >> ObjLayerT Objlayer; >> CompileLayerT Compilelayer (Objlayer, llvm::orc::SimpleCompiler(*TM)); >> std::unique_ptr<llvm::Module> M (new llvm::Module("module", Context)); >> M->setDataLayout (*DL); >> >> // Declare stub for external function sqr >> auto type_float = llvm::Type::getFloatTy (Context); >> llvm::Typ...

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but

...:ModuleSetHandleT ModuleHandle; >>>>>> >>>>>> KaleidoscopeJIT() >>>>>> : TM(EngineBuilder().selectTarget()), >>>>>> DL(TM->createDataLayout()), >>>>>> CompileLayer(ObjectLayer, SimpleCompiler(*TM)) { >>>>>> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); >>>>>> } >>>>>> >>>>>> TargetMachine &getTargetMachine() { return *TM; } >>>>>> >>>>>> Modul...