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

Roman Kennke rkennke at redhat.com
Mon Nov 12 23:30:52 UTC 2018

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


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

More information about the hotspot-compiler-dev mailing list