Optimizing byte reverse code for int value

Doerr, Martin martin.doerr at sap.com
Tue Apr 11 15:12:50 UTC 2017


Hi Michihiro,

thanks for the quick reply.

I think Andrew’s idea is to optimize in the shared code instead of the platform backends. I haven’t thought about where this could be done.
Or would it be possible to backport jdk (especially Unsafe) changes? If the required changes are small enough and we don’t have to touch any public interface, this might be an option, too.

We’ll appreciate if you take care of the new match rules for PPC64. Thanks a lot.

Best regards,
Martin


From: Michihiro Horie [mailto:HORIE at jp.ibm.com]
Sent: Dienstag, 11. April 2017 16:55
To: Doerr, Martin <martin.doerr at sap.com>
Cc: aph at redhat.com; Hiroshi H Horii <HORII at jp.ibm.com>; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker <volker.simonis at sap.com>
Subject: RE: Optimizing byte reverse code for int value

Andrew, Martin,

Thanks a lot for your helpful feedback.

>Have you considered it as a generic optimization for all processors?
We would support all processors for our byte-reverse optimization to make it generic.
Currently, I just finished adding match rules for little endian and big endian on PPC64, and am testing it in AIX.

>In addition, I noticed that we don't have match rules which exploit byte reverse load/store instructions on PPC64.
We would like to handle adding match rules for byte reverse load/store instructions on PPC64 for JDK10 if you would not mind.
Would it be fine with you?

Best regards,
--
Michihiro,
IBM Research - Tokyo


----- Original message -----
From: "Doerr, Martin" <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
To: Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>, Michihiro Horie/Japan/IBM at IBMJP
Cc: "Simonis, Volker" <volker.simonis at sap.com<mailto:volker.simonis at sap.com>>, "ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>" <ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>>, "hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>" <hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>>, Hiroshi H Horii/Japan/IBM at IBMJP
Subject: RE: Optimizing byte reverse code for int value
Date: Tue, Apr 11, 2017 10:44 PM

Hi Andrew,

thank you for your helpful comments. I fully agree with you.

In addition, I noticed that we don't have match rules which exploit byte reverse load/store instructions on PPC64.
SPARC already has them:
match(Set dst (ReverseBytesI/L/US/S (LoadI src)));
match(Set dst (StoreI dst (ReverseBytesI/L/US/S src)));
I think we should add them for jdk10. They should be used when the platform endianness doesn't match the bigEndian parameter in Unsafe methods.

Best regards,
Martin


-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley
Sent: Dienstag, 11. April 2017 13:02
To: Michihiro Horie <HORIE at jp.ibm.com<mailto:HORIE at jp.ibm.com>>
Cc: Simonis, Volker <volker.simonis at sap.com<mailto:volker.simonis at sap.com>>; ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>; hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>; Hiroshi H Horii <HORII at jp.ibm.com<mailto:HORII at jp.ibm.com>>
Subject: Re: Optimizing byte reverse code for int value

On 11/04/17 11:36, Michihiro Horie wrote:
> Thank you very much for letting us know Unsafe.getIntUnaligned is available in
> JDK9. I do agree we should fix Java source code.
> We think our byte-reverse optimization would still work on jdk8u as Hiroshi
> mentioned. Would you agree on this point?

I do, but I do not agree that this patch should necessarily be done in
the PowerPC-specific back end.  Have you considered it as a generic
optimization for all processors?

Andrew.




More information about the hotspot-dev mailing list