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

[Chris Lattner]

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

Ok, sounds good.  Here are some comments:

1. This does not apply cleanly to mainline CVS, please update and try
    again :)
2. Please keep lines within 80 columns.
3. This will fail if the JIT wants to allocate more than 512K of
    constants.  Can you just have it allocate another block of memory if it
    runs out of space?  Also, it might be useful to start the initial block
    much smaller, say 4K of memory, and double it when space is
    exhausted, as most programs don't use 1/2 meg of constant pools :)

> 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.

There is a (currently unimplemented) method for doing this:
ExecutionEngine::freeMachineCodeForFunction.

It should be straight-forward to free the memory for a function, though it 
will make the JITEmitter a bit more complex (it will have to track regions 
of freed memory) to reallocate them.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/