llvm dev - Dec 2004 - [LLVMdev] FP Constants spilling to memory in x86 code generation

Hello,

I've tracked down a new memory leak which started happening when I 
enabled constant propagation (I created my own passmanager which I run 
before calling getPointerToGlobal to JIT the function I have generated - 
is this OK?). The reason is that FP constants are being spilled to 
memory as there is no immediate fp load available. In my case this is a 
bit unnecessary since the constant is in fact a (constant) global 
variable which I have already added a memory mapping for. But the 
constant folding can of course end up making new constants which _have_ 
to be spilled to memory.

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? If not, I have to add 
tracking to the allocations here so they can be freed when the function 
is deleted. This is not so easy since there is no reference to the 
function which we are generating machine code for inside the 
copyConstantToRegister function. Any ideas?

m.

PS. Regarding my earlier post about function stubs -- The stub 
generation is working fine for the x86 target, it was Visual Studio 
generating the stubs I was seing because I have Fix&Continue turned on :-P

On Mon, 6 Dec 2004, Morten Ofstad wrote:
> Hello,
>
> I've tracked down a new memory leak which started happening when I
enabled
> constant propagation (I created my own passmanager which I run before
calling
> getPointerToGlobal to JIT the function I have generated - is this OK?).
Yes, that's perfectly ok!  The interface to do this could probably be 
improved, but I definitely intended for JIT applications like yours to add 
standard (and even custom) passes to the pass manager to be run 
automatically before the JIT runs.
> The reason is that FP constants are being spilled to memory as there is 
> no immediate fp load available. In my case this is a bit unnecessary 
> since the constant is in fact a (constant) global variable which I have 
> already added a memory mapping for. But the constant folding can of 
> course end up making new constants which _have_ to be spilled to memory.
Okay, if you're using X86 FP math, there is really little choice except to 
spill the FP constant to the constant pool for a function.  This should be 
completely transparent to you.
> 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.
> If not, I have to add tracking to the allocations here so they can be 
> freed when the function is deleted. This is not so easy since there is 
> no reference to the function which we are generating machine code for 
> inside the copyConstantToRegister function. Any ideas?
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.
> PS. Regarding my earlier post about function stubs -- The stub generation
is
> working fine for the x86 target, it was Visual Studio generating the stubs
I
> was seing because I have Fix&Continue turned on :-P
Ah, ok, good deal! :)

-Chris

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

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>