[8u] RFR for backport of JDK-8188868: PPC64: Support AES intrinsics on Big Endian

[Kazunori Ogata]

Hi Martin,

I noticed that the changeset JDK-8188868 [1] also needs load_perm() and 
vec_prem(), which are added in another changeset "8185979: PPC64: 
Implement SHA2 intrinsic" [2].  I'm sorry, but I forgot about these two 
functions when I posted my RFR.

The issue is that applying [2] causes a long chain of dependency, as shown 
below in depending order, and it eventually reached two changesets [5][6] 
that seem to be difficult to backport to JDK8.  [5] is for the compact 
string feature, which is not supported in JDK8, and [6] is a big bundle of 
changes.

Is it acceptable as a back port process to cherry pick a few methods from 
a dependent changeset, instead of applying whole changeset? 

Possible candidates of cherry picking are:

1. Pick load_perm() and vec_perm() from [2]
2. Pick vst() and vsix() from [3], and apply [2]
3. Pick has_vsx() and vsr[abst]() from [4], and apply [3] and above
4. Pick has_mfdscr() from [5] and config_dscr() from [6], and apply [4] 
and above. 

I appreciate your suggestion.


[1] 8188868: PPC64: Support AES intrinsics on Big Endian
    http://hg.openjdk.java.net/jdk/jdk/rev/9d337e48b178
[2] 8185979: PPC64: Implement SHA2 intrinsic
    http://hg.openjdk.java.net/jdk/jdk/rev/f4962ab855b6
[3] 8185969: PPC64: Improve VSR support to use up to 64 registers
    http://hg.openjdk.java.net/jdk/jdk/rev/057f21a10f5f
[4] 8154156: PPC64: improve array copy stubs by using vector instructions
    http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e
[5] 8149655: PPC64: Implement CompactString intrinsics
    http://hg.openjdk.java.net/jdk/jdk/rev/6241574f5982
[6] 8077838: Recent developments for ppc.
    http://hg.openjdk.java.net/jdk/jdk/rev/c703c89fddbf


Regards,
Ogata


"hotspot-compiler-dev" <hotspot-compiler-dev-bounces at openjdk.java.net> 
wrote on 2018/11/19 18:12:45:

> From: "Kazunori Ogata" <OGATAK at jp.ibm.com>
> To: "Doerr, Martin" <martin.doerr at sap.com>
> Cc: "hotspot-compiler-dev at openjdk.java.net" <hotspot-compiler-
> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" 
<ppc-aix-port-
> dev at openjdk.java.net>
> Date: 2018/11/19 18:16
> Subject: RE: [8u] RFR for backport of JDK-8188868: PPC64: Support AES 
> intrinsics on Big Endian
> Sent by: "hotspot-compiler-dev" 
<hotspot-compiler-dev-bounces at openjdk.java.net>
> 
> Hi Martin,
> 
> Thank you for your comment.  I see.  I'll backport JDK-8185975 first.
> 
> > Please don't forget to test the debug build.
> Yes, I'll test both debug and release builds.
> 
> 
> Regards,
> Ogata
> 
> 
> 
> From:   "Doerr, Martin" <martin.doerr at sap.com>
> To:     Kazunori Ogata <OGATAK at jp.ibm.com>, 
> "hotspot-compiler-dev at openjdk.java.net" 
> <hotspot-compiler-dev at openjdk.java.net>, 
> "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>
> Date:   2018/11/19 17:56
> Subject:        RE: [8u] RFR for backport of JDK-8188868: PPC64: Support 

> AES intrinsics on Big Endian
> 
> 
> 
> Hi Ogata,
> 
> you need to backport JDK-8185975 before you can use +8 instead of -8.
> Please don't forget to test the debug build.
> 
> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: hotspot-compiler-dev 
<hotspot-compiler-dev-bounces at openjdk.java.net> 
> On Behalf Of Kazunori Ogata
> Sent: Montag, 19. November 2018 09:28
> To: hotspot-compiler-dev at openjdk.java.net; 
> ppc-aix-port-dev at openjdk.java.net
> Subject: [8u] RFR for backport of JDK-8188868: PPC64: Support AES 
> intrinsics on Big Endian
> 
> Hi,
> 
> May I get reviews for enhancement backport of JDK-8188868: PPC64: 
Support 
> AES intrinsics on Big Endian?
> 
> INVALID URI REMOVED
> u=http-3A__cr.openjdk.java.net_-7Ehorii_jdk8u-5Faes-5Fbe_8188868_webrev.
> 00_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=p-
> 
FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=BqxW_dQ87Y0TOxyOjkH6hFZIIrhwH2ycEWJdxSDcAeQ&s=ulzXDyQq40EaguNM-
> svdR9rWGZnClO3c3d_41XGFuHg&e=
> 
> 
> There is no code change except for an immediate parameter of vsldoi (-8 
in 
> 
> jdk8u was changed to 8 to match with the latest code), besides the 
> difference of directory tree structure.
> 
> Since not a small number of customers are still using jdk8, especially 
in 
> AIX, JDK-8188868 is important for them to improve performance of secure 
> network transportation.
> 
> 
> Regards,
> Ogata
> 
> 
> 
> 
> 
>