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

[Roman Kennke]

Hi Vladimir,

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

Roman


> If you keep CallLeafNoFP (in new form) we can't clean up NO_FP code as I
> wanted :(
> 
> thanks,
> Vladimir
> 
>> - I guess it makes sense to consider all existing NoFP calls to use that
>> new NoFP because it provides real benefits
>> - Yes, Shenandoah will use/emit the new CallLeafNoFP, but not during
>> parsing but while expanding its barriers
>>
>> Does that answer your questions?
>>
>> Roland should confirm if I got that right though ;-)
>>
>> Thanks,
>> Roman
>>
>>
>>> Hi, Roland
>>>
>>> First, please explain your comment:
>>>
>>> "That stuff is for parse time. We emit our CallLeafNoFP after parse
>>> time. So we don't need that stuff."
>>>
>>> Do you intent to add new CallLeafNoFP for Shenandoah?  Or you can use
>>> normal CallLeaf since there are no difference (except 32-bit x86).
>>>
>>> Do you still need additional parameter exclude_fp in add_call_kills()?
>>>
>>> And, please, file new RFE to remove NO_FP code.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 11/12/18 1:01 AM, Roland Westrelin wrote:
>>>>
>>>>> Looking on all .ad files I see difference only for x86_32:
>>>>
>>>> I missed that.
>>>>
>>>>> http://hg.openjdk.java.net/jdk/jdk/file/13266dac5fdb/src/hotspot/cpu/x86/x86_32.ad#l13326
>>>>>
>>>>>
>>>>>
>>>>> And I surprise we don't have difference for SPARC.
>>>>>
>>>>> Your change make code in x86_32 be unused. The only drawback to
>>>>> always use CallLeaf there is empty_FPU_stack() when cpu
>>>>> does not have SSE2 (such CPUs should disappear already) and reset FPU
>>>>> control word when it is in special 24BitFPMode
>>>>> mode. The 24bit mode most likely is not used any more (requires not
>>>>> presence SSE and other conditions):
>>>>>
>>>>> http://hg.openjdk.java.net/jdk/jdk/file/13266dac5fdb/src/hotspot/share/opto/compile.cpp#l3678
>>>>>
>>>>>
>>>>>
>>>>> Based on this I think we need purge all this vary outdated code as
>>>>> separate RFE.
>>>>>
>>>>> Lets first push your changes.
>>>>
>>>> Ok. Thanks. So you're ok with this?
>>>>
>>>> Roland.
>>>>
>>

-------------- 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/36cfc3b8/signature.asc>