Displaying 4 results from an estimated 4 matches for "jitmm".
Did you mean:
jimm
2014 Jan 20
2
[LLVMdev] MCJIT versus getLazyBitcodeModule?
...ions in the bitcode like "foo", if that's what I called it in the original .cpp file that was turned into bitcode.
* Traditionally, I have created a JIT execution engine like this:
m_llvm_exec = llvm::ExecutionEngine::createJIT (module(), err,
jitmm(), llvm::CodeGenOpt::Default,
/*AllocateGVsWithCode*/ false);
All has worked fine, this is a system that's seen heavy production use for a couple years now.
Now I'm trying to make this codebase work with MCJIT, and I've run into some trouble. Here&...
2004 Dec 13
0
[LLVMdev] FP Constants spilling to memory in x86 code generation
On Mon, 13 Dec 2004, Morten Ofstad wrote:
> I have made a patch along these lines. Although I reused the JITMemoryManager
> object, I am allocating constant pools from another block of memory. This
> fixes my remaining leaks. It would be nice if also the global variables were
> allocated in this way, but it's not needed for my application since I'm
> managing that memory
2005 Jan 03
1
[LLVMdev] FP Constants spilling to memory in x86 code generation
...compilation is finished and you know the size of
the function. This approach require relocation information to be
generated as part of the compilation process.
m.
PS. Happy new year everyone!
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jitmm.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050103/d8f63cc7/attachment.ksh>
2004 Dec 13
2
[LLVMdev] FP Constants spilling to memory in x86 code generation
Chris Lattner wrote:
> On Mon, 6 Dec 2004, Morten Ofstad wrote:
>> I guess what I'd like to know is if the process of spilling constants
>> to memory could be a bit more controlled, maybe using the JIT memory
>> manager and putting it in with the function stubs?
>
> Yes, this can and should definitely be improved. If you look at
>