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

[Vladimir Kozlov]

On 11/12/18 3:30 PM, Roman Kennke wrote:
> 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?

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