[8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: Implement SHA2 intrinsic

[Doerr, Martin]

Hi Ogata,

looks correct.

Best regards,
Martin


> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of Kazunori Ogata
> Sent: Donnerstag, 6. Juni 2019 09:55
> To: hotspot-compiler-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64:
> Implement SHA2 intrinsic
> 
> Hi,
> 
> May I get review of non-clean backport of 8185979: PPC64: Implement SHA2
> intrinsic?
> 
> The original patch itself can be applied cleanly (besides difference of
> the source directory structure).  However, in jdk8u, it also needs to
> change the arguments of make_runtime_call() based on the
> CCallingCenventionRequiresAsLongs flag.  So I made additional changes to
> src/share/vm/opto/library_call.cpp and runtime.cpp.
> 
> To separate the change in the original patch and the additional changes, I
> made webrev incrementally.  webrev.02 below only contains the changes by
> the original patch, and webrev.03 contains all changes including the
> additional ones.  The difference between the two webrevs is the changes in
> library_call.cpp and runtime.cpp.
> 
> 
> Original bug report:
> https://bugs.openjdk.java.net/browse/JDK-8185979
> 
> Webrev based on the original patch:
> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.02/
> 
> Webrev of all changes:
> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.03/
> 
> 
> I verified there is no degradation in jtreg (make test) results in both
> fastdebug and release builds.
> 
> 
> Regards,
> Ogata