[LLVMdev] llvm register reload/spilling around calls

Roland Scheidegger sroland at vmware.com
Tue Oct 19 18:37:06 PDT 2010


Thanks for giving it a look!

On 19.10.2010 23:21, Jakob Stoklund Olesen wrote:
> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote:
> 
>> So I saw that the code is doing lots of register
>> spilling/reloading. Now I understand that due to calling
>> conventions, there's not really a way to avoid this - I tried using
>> coldcc but apparently the backend doesn't implement it and hence
>> this is ignored.
> 
> Yes, unfortunately the list of call-clobbered registers is fixed at
> the moment, so coldcc is mostly ignored by the backend.
> 
> Patches welcome.
What would be needed there? I actually tried a quick hack and simply
changed the registers included in the list in
X86RegisterInfo::getCalleeSavedRegs, so some xmm regs were included
(similar to what was done for win64). But the result wasn't what I
expected - the callee now indeed saved/restored all the xmm regs I
added, however the calling code did not change at all...

> 
>> So is there any optimization option I'm missing which could improve
>>  this? Or is this simply the way things are (would that be
>> considered a bug?). If this is a known limitation, any ideas if
>> it's possible to work around that (by changing the affected jit
>> code)?
> 
> The -pre-alloc-split option should handle stuff like this when calls
> clobber an entire register class. That probably only applies to XMM
> registers.
I tried that and the generated code did not change at all.

> 
> Work on proper live range splitting is in progress. You can try it
> out with -spiller=inline, but it is highly experimental and volatile
> at the moment.
Tried that too but the code mostly remained the same (there were 2
additional spills right at the beginning and some of the register
numbers changed but that was all).
There's also a -spiller=splitting option, I don't know what it should do
but it just crashed...

Roland

> 
> I don't know any short term solutions.
> 
> /jakob
> 




More information about the llvm-dev mailing list