RFR(M): 8213528: fp registers should not need to be saved around a CallLeafNoFP

[Vladimir Kozlov]

Thank you, Roman, for explanation.

Save/restore XMM registers in a wrapper stub is perfectly fine with me. May be we should name such calls differently - 
NO_FP is misleading.

I agree that we should avoid touching C2's RA.

Thanks,
Vladimir

On 11/13/18 4:16 PM, Roman Kennke wrote:
>>
>>>> I think the idea is to:
>>>> - turn all existing CallLeafNoFP into CallLeaf because the way it is
>>>> implemented now, it's really the same, and using CallLeaf is the
>>>> conservative move
>>>
>>> Yes, that is what Roland's patch do. I agree with that. Except it change
>>> behavior for 32-bit x86 which I think is fine.
>>>
>>>> - Fix CallLeafNoFP to do what it's presumably supposed to do: don't
>>>> save/restore FP registers around calls because NoFP calls are
>>>> known/guaranteed to not touch them
>>>
>>> That is what I don't get. Why you need CallLeafNoFP? And where you have
>>> guarantee that runtime code you are calling don't use XMM registers?
>>
>> We don't call straight into runtime. We call into a stub first, which
>> would save/restore XMM registers.
>>
>> The advantage is not immediately obvious: one might ask: why not let the
>> compiler/regalloc sort out what to save and restore around calls? We
>> found out that our runtime calls for barriers would disturb xmm
>> spilling. Where code without barriers would happily use XMM spilling,
>> having a runtime call (without NoFP) there would prevent that and do
>> actual stack spilling (because FP regs are no longer guaranteed to be
>> free), which leads to significant slowdown. So we changed to call into
>> NoFP call into a stub (that does the FP save/restore), and bingo we
>> would get XMM spilling back around our runtime calls. You might still
>> ask: sure, but you gotta save/restore XMM regs anyway, so what? The
>> point is that we'd call into runtime relatively rarely (and then we can
>> accept the extra cost of blindly saving/restoring all XMM regs), but the
>> runtime call would prevent XMM spilling around it even for the fast
>> path, even when it's never called.
>>
>> I hope that clarifies a little where we are coming from. I suspect the
>> approach may be useful for other GCs and maybe even outside GCs. Or
>> maybe we can come up with an even better solution to our problem? I'd be
>> happy to have the compiler/regalloc save/restore XMM regs *and* keep XMM
>> spilling alive if that is possible.
> 
> IOW, I think the optimal solution would be to improve the register
> allocator to not disable FP spilling altogether if it sees anything that
> kills FP (e.g. a CallLeaf), but instead keep track of FP spills and
> save/restore those FP regs around the actual call. However, nobody that
> I know seems to dare to touch the register allocator. Maybe you have an
> idea?
> 
> Roman
> 
>