search for: createdefaultmemmanag

...9;s turn needs an LLVMContext, which I'm trying to create for each new request. > Does anyone have additional ideas for how to handle this? Or whether there is another approach that could work here? I derived a class from JITMemoryManager which delegates everything to an instance made with CreateDefaultMemManager(). ExecutionEngine destroys the wrapper, but I keep the inner instance which did the actual work. Works, but seems a bit ugly. Did you find any other solutions?

On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: > I derived a class from JITMemoryManager which delegates everything to > an instance made with CreateDefaultMemManager(). ExecutionEngine > destroys the wrapper, but I keep the inner instance which did the > actual work. Works, but seems a bit ugly. Did you find any other > solutions? I ended up implementing the exact same thing, it feels dirty but it has worked great for us so far. -- Dirkjan

...ept endFunctionBody. > > Here's how vmkit does it: class MvmMemoryManager : public JITMemoryManager { /// realMemoryManager - The real allocator JITMemoryManager* realMemoryManager; public: MvmMemoryManager() : JITMemoryManager() { realMemoryManager = JITMemoryManager::CreateDefaultMemManager(); } And MvmMemoryManager redefines all the virtual functions to call the real memory manager. For endFunctionBody, it inserts in a map the start and end pointers. Good luck! Nicolas > Thanks, > Andrew. > > _______________________________________________ > LLVM Developers...

Here's my problem, which I raised on IRC: JIT::getPointerToFunction gets the address of the start of a function. But how do I find out where the end of the function is? I need this to register the function for profiling. varth said: aph, you need to intercept the "endFunctionBody" call on the memory manager, it will tell you the start pointer and the end pointer But how can I do

...32? On Sat, Mar 16, 2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com> wrote: > > On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: > >> I derived a class from JITMemoryManager which delegates everything to >> an instance made with CreateDefaultMemManager(). ExecutionEngine >> destroys the wrapper, but I keep the inner instance which did the >> actual work. Works, but seems a bit ugly. Did you find any other >> solutions? > > I ended up implementing the exact same thing, it feels dirty but it has worked great for us so f...

...2? On Sat, Mar 16, 2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com> wrote: > > On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: > >> I derived a class from JITMemoryManager which delegates everything to >> an instance made with CreateDefaultMemManager(). ExecutionEngine >> destroys the wrapper, but I keep the inner instance which did the >> actual work. Works, but seems a bit ugly. Did you find any other >> solutions? > > I ended up implementing the exact same thing, it feels dirty but it has worked great for us s...

...13 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com> wrote: >> >> On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: >> >>> I derived a class from JITMemoryManager which delegates everything to >>> an instance made with CreateDefaultMemManager(). ExecutionEngine >>> destroys the wrapper, but I keep the inner instance which did the >>> actual work. Works, but seems a bit ugly. Did you find any other >>> solutions? >> >> I ended up implementing the exact same thing, it feels dirty but it has...

...vmkit does it: > > class MvmMemoryManager : public JITMemoryManager { > > /// realMemoryManager - The real allocator > JITMemoryManager* realMemoryManager; > > public: > > MvmMemoryManager() : JITMemoryManager() { > realMemoryManager = JITMemoryManager::CreateDefaultMemManager(); > } > > > And MvmMemoryManager redefines all the virtual functions to call the > real memory manager. For endFunctionBody, it inserts in a map the start > and end pointers. So I have to define *all* the virtual functions and wrap the memory manager just in order to int...

...2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com> wrote: >> >> On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: >> >>> I derived a class from JITMemoryManager which delegates everything to >>> an instance made with CreateDefaultMemManager(). ExecutionEngine >>> destroys the wrapper, but I keep the inner instance which did the >>> actual work. Works, but seems a bit ugly. Did you find any other >>> solutions? >> >> I ended up implementing the exact same thing, it feels dirty but it has work...

...2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com> wrote: >> >> On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: >> >>> I derived a class from JITMemoryManager which delegates everything to >>> an instance made with CreateDefaultMemManager(). ExecutionEngine >>> destroys the wrapper, but I keep the inner instance which did the >>> actual work. Works, but seems a bit ugly. Did you find any other >>> solutions? >> >> I ended up implementing the exact same thing, it feels dirty but it has work...

Hi, I am using llvm to generate jit code for numerical computation on window 7 64 platform. There is a function call, pow, in the jit code. The problem is that at run time, the pow function call sometimes links to msvcrt.dll, and sometimes to msvcr100.dll. These two calls from two dlls return different results, causing sporadic results. I tried to make the pow function either intrinsic or

Folks, Is anyone else the failure below? On Mac OS X everything builds properly... Thanks for any help, snaroff -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 27.png Type: image/png Size: 18959 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081217/e7d37fee/attachment.png>

...2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com> wrote: >> >> On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: >> >>> I derived a class from JITMemoryManager which delegates everything >>> to an instance made with CreateDefaultMemManager(). ExecutionEngine >>> destroys the wrapper, but I keep the inner instance which did the >>> actual work. Works, but seems a bit ugly. Did you find any other >>> solutions? >> >> I ended up implementing the exact same thing, it feels dirty but it has w...

...MCE; > + const MRegisterInfo* RI; > + > + public: > + DwarfJITEmitter(MachineCodeEmitter &mce, const TargetData& td, > + TargetMachine& tm) : TD(td), TM(tm), MCE(mce) { > + RI = TM.getRegisterInfo(); > + MemMgr = JITMemoryManager::CreateDefaultMemManager(); > + } > + > + unsigned char* EmitExceptionTable(MachineFunction* MF, > + unsigned char* StartFunction, > + unsigned char* EndFunction); > + > + void EmitFrameMoves(intptr_t BaseLabelPtr, &gt...

...gisterInfo* RI; >> + >> + public: >> + DwarfJITEmitter(MachineCodeEmitter &mce, const TargetData& td, >> + TargetMachine& tm) : TD(td), TM(tm), MCE(mce) { >> + RI = TM.getRegisterInfo(); >> + MemMgr = JITMemoryManager::CreateDefaultMemManager(); >> + } >> + >> + unsigned char* EmitExceptionTable(MachineFunction* MF, >> + unsigned char* StartFunction, >> + unsigned char* EndFunction); >> + >> + void EmitFrameMove...

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

...e("LLVM Test", *LLVM_Context); if (!LLVM_Module) { Err.print(argv[0], llvm::errs()); return 1; } std::string ErrorMsg; llvm::EngineBuilder builder(LLVM_Module); builder.setErrorStr(&ErrorMsg); builder.setJITMemoryManager(llvm::JITMemoryManager::CreateDefaultMemManager()); builder.setEngineKind(llvm::EngineKind::JIT); //CodeGenOpt::Level OLvl = CodeGenOpt::Default; //builder.setOptLevel(OLvl); llvm::TargetOptions Options; Options.JITExceptionHandling = false; Options.JITEmitDebugInfo = false; Options.JITEmitDebugInfoToDisk = false...

...ector<intptr_t> LabelLocations; > + > + /// MMI - Machine module info for exception informations > + MachineModuleInfo* MMI; > + > public: > JITEmitter(JIT &jit, JITMemoryManager *JMM) : Resolver(jit) { > MemMgr = JMM ? JMM : > JITMemoryManager::CreateDefaultMemManager(); > @@ -343,9 +357,12 @@ > MemMgr->AllocateGOT(); > DOUT << "JIT is managing a GOT\n"; > } > + > + if (ExceptionHandling) DE = new JITDwarfEmitter(jit); > } > ~JITEmitter() { > delete MemMgr; > + if (E...

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL: