[LLVMdev] FP Constants spilling to memory in x86 code generation

Morten Ofstad morten at hue.no
Mon Dec 13 11:25:57 PST 2004


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 
> ExecutionEngine/JIT/JITEmitter.cpp:emitConstantPool, you can see that 
> the JIT is just new'ing a block of memory for every constant pool that 
> is needed.  This is, admittedly, antisocial for your application, so if 
> you'd like to make a memory manager for it, feel free.
 >
> I think that adding something like the JITMemoryManager for the constant 
> pools would make sense.  I'm not sure that reusing the JITMemoryManager 
> is a great idea, though it could be done.  In particular, some 
> architectures have cache problems when data and code live too close to 
> each other.  I'm not familiar with the details, but it seems safe to put 
> constants somewhere that is not intentionally close to the code.  
> Perhaps others have a more informed opinion about this than I do.

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 myself and using 
ExecutionEngine::addGlobalMapping.

Later on I'm going to need either a way of freeing memory for 
functions/constant pools or a way of recovering from out of memory, as 
our application is going to run as a server and hopefully be happily 
JIT'ing away for days on end. For the moment I will just delete the 
whole ExecutionEngine object and recompile everything every now and 
again. Although not a perfect solution, at least it works.

m.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041213/636701ff/attachment.txt>


More information about the llvm-dev mailing list