Optimizing byte reverse code for int value

Wed Apr 26 03:09:33 UTC 2017

Martin,

Thanks a lot for your comments. I fixed my code.
Webrev: http://cr.openjdk.java.net/~horii/8178294/webrev.05/

Best regards,
--
Michihiro,
IBM Research - Tokyo

From:	"Doerr, Martin" <martin.doerr at sap.com>
To:	Michihiro Horie/Japan/IBM at IBMJP
Cc:	"aph at redhat.com" <aph at redhat.com>, Hiroshi H
            Horii/Japan/IBM at IBMJP, "hotspot-dev at openjdk.java.net"
            <hotspot-dev at openjdk.java.net>,
            "ppc-aix-port-dev at openjdk.java.net"
            <ppc-aix-port-dev at openjdk.java.net>, "Simonis, Volker"
            <volker.simonis at sap.com>, Gustavo Bueno Romero
            <gromero at br.ibm.com>
Date:	2017/04/24 18:11
Subject:	RE: Optimizing byte reverse code for int value

Hi Michihiro,

please note that I’m not a jdk8u reviewer.
However, I have taken a quick look and I have the following concerns:
      1.       I think it’s incorrect for Big Endian.
      2.       The pattern can also match for an unaligned 4 byte address
      which would break platforms like SPARC.
      3.       I couldn’t see checks for shift amount and masks.

Best regards,
Martin

From: Michihiro Horie [mailto:HORIE at jp.ibm.com]
Sent: Freitag, 21. April 2017 18:18
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>; Gustavo Bueno Romero <gromero at br.ibm.com>
Subject: RE: Optimizing byte reverse code for int value

Would you review following change for jdk8?

Webrev: http://cr.openjdk.java.net/~horii/8178294/webrev.01/

Our byte-reverse optimization now works in shared code. I tested it with
jtreg on x86, ppc64, and ppc64le.
Best regards,
--
Michihiro,
IBM Research - Tokyo

 ----- Original message -----
 From: "Doerr, Martin" <martin.doerr at sap.com>
 To: Michihiro Horie/Japan/IBM at IBMJP
 Cc: "aph at redhat.com" <aph at redhat.com>, Hiroshi H Horii/Japan/IBM at IBMJP, "
 hotspot-dev at openjdk.java.net" <hotspot-dev at openjdk.java.net>, "
 ppc-aix-port-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
 Date: Wed, Apr 12, 2017 12:13 AM

 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>
 To: Andrew Haley <aph at redhat.com>, Michihiro Horie/Japan/IBM at IBMJP
 Cc: "Simonis, Volker" <volker.simonis at sap.com>, "
 ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, "
 hotspot-dev at openjdk.java.net" <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>
 Cc: Simonis, Volker <volker.simonis at sap.com>;
 ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Hiroshi H
 Horii <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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170426/98c7f2a8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170426/98c7f2a8/graycol.gif>