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
- 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
- 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/20181113/14962bcb/signature.asc>