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

[Roman Kennke]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20181114/a98b4033/signature.asc>