search for: classllvm_1_1jit

...; *including* removing the anonymous procedure name from any global symbol > table (if any) and also advising the runtime that the associated IR > module can now be dropped along with everything else that was generated? Freeing the machine code is straightforward: http://llvm.org/doxygen/classllvm_1_1JIT.html#a8 Not sure about the Function instance itself. The delete operator would be my first guess. Sandro

...(*function_t)(methodOop method, JavaThread *thread); > function_t func = [some LLVM call here]; > func(method, thread); > > That would solve pretty much all my problems :) The getPointerToFunctionOrStub method that does what you want in the JIT. http://llvm.org/docs/doxygen/html/classllvm_1_1JIT.html#a6 — Gordon

On Wed, 2008-03-26 at 10:40 -0700, Chris Lattner wrote: > On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > > The Kaleidoscope tutorial has us "interpreting" top-level expressions by > > generating a one-shot anonymous procedure and executing that. Once the > > expressions have been executed, these procedures will never be called > > again. > > > >

Hi all, I've been working on making a non-architecture specific port of OpenJDK these past few months. It's interpreter-only at present, and very slow, and I'd like to use LLVM to add some kind of JIT to it. So far I'm just trying to figure out how it would all slot in. The existing code in OpenJDK is written to accomodate different JITs, so integrating peripheral stuff like

...another way I might be missing? Or would I have to subclass JITEmitter and add a method to perform this calculation? Finally, can I free the memory used by the in-memory IR after the code is generated? Sandro [1] http://llvm.org/doxygen/classllvm_1_1Function.html#a27 [2] http://llvm.org/doxygen/classllvm_1_1JIT.html [3] http://llvm.org/doxygen/classllvm_1_1MachineCodeEmitter.html

...low up with whether the JIT uses stub functions >> which would enable dynamic relinking If not, it would be a >> straightforward, if platform-specific, feature to add. > > I don't use proxy or stub functions, I relink them... I misspoke. See here: http://llvm.org/doxygen/classllvm_1_1JIT.html#a7 Relinking the function as you describe is risky in the case that the address of the function has been taken. LLVM's present approach is general. — Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/a...

...ine code jit'd. > Finally, can I free the memory used by the in-memory IR after the code > is generated? Yes, you can call F->deleteBody() after JIT'ing F. -Chris > Sandro > > [1] http://llvm.org/doxygen/classllvm_1_1Function.html#a27 > [2] http://llvm.org/doxygen/classllvm_1_1JIT.html > [3] http://llvm.org/doxygen/classllvm_1_1MachineCodeEmitter.html > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

----- Original Message ----- From: "Gordon Henriksen" <gordonhenriksen at mac.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Wednesday, October 24, 2007 1:45 AM Subject: Re: [LLVMdev] me being stupid: me vs the llvm codebase... On Oct 23, 2007, at 05:52, BGB wrote: > I am assuming then that some external assembler is used (such as >

...someone will follow up with whether the JIT uses stub functions which would enable dynamic relinking If not, it would be a straightforward, if platform-specific, feature to add. I don't use proxy or stub functions, I relink them... I misspoke. See here: http://llvm.org/doxygen/classllvm_1_1JIT.html#a7 Relinking the function as you describe is risky in the case that the address of the function has been taken. LLVM's present approach is general. — Gordon ------------------------------------------------------------------------------ _____________________________________...