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

[Gustavo Romero]

Hi Ogata,

Thanks a lot for backporting it.

HotSpot changes look good, only the Jtreg part needs a small fix, apparently.

Sorry for not mentioning it earlier, I just noticed it before pushing.

Jtreg is falling with:

/home/gromero/hg/upstream/jdk8u-dev/hotspot/test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java:70: error: constructor OrPredicate in class OrPredicate cannot be applied to given types;
               new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new String[] { "sha"    },
               ^
   required: BooleanSupplier,BooleanSupplier
   found: CPUSpecificPredicate
   reason: actual and formal argument lists differ in length
/home/gromero/hg/upstream/jdk8u-dev/hotspot/test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java:79: error: constructor OrPredicate in class OrPredicate cannot be applied to given types;
               new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new String[] { "sha"    },
               ^
   required: BooleanSupplier,BooleanSupplier
   found: CPUSpecificPredicate
   reason: actual and formal argument lists differ in length
2 errors

and I got all SHA tests passing with:

diff -r 1dc0df528dbc test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java
--- a/test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java  Mon Jun 17 09:21:58 2019 -0400
+++ b/test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java  Mon Jun 17 10:35:21 2019 -0400
@@ -67,18 +67,18 @@
                                                        null),
                new OrPredicate(new CPUSpecificPredicate("ppc64.*",   new String[] { "sha"    },
                                                        null),
-              new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new String[] { "sha"    },
-                                                      null)
-                             )));
+                              new CPUSpecificPredicate("ppc64le.*", new String[] { "sha"    },
+                                                       null)
+                             ));
  
      public static final BooleanSupplier SHA512_INSTRUCTION_AVAILABLE
              = new OrPredicate(new CPUSpecificPredicate("sparc.*",   new String[] { "sha512" },
                                                        null),
                new OrPredicate(new CPUSpecificPredicate("ppc64.*",   new String[] { "sha"    },
                                                        null),
-              new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new String[] { "sha"    },
+                              new CPUSpecificPredicate("ppc64le.*", new String[] { "sha"    },
                                                        null)
-                             )));
+                             ));
  
      public static final BooleanSupplier ANY_SHA_INSTRUCTION_AVAILABLE
              = new OrPredicate(IntrinsicPredicates.SHA1_INSTRUCTION_AVAILABLE,

Sometimes JTwork dir can contain stale tests, so it's necessary to ensure it's
cleared so new changes are effective.

Could you please confirm the fix above is correct?

Thank you.

Best regards,
Gustavo


On 06/06/2019 05:45 AM, Kazunori Ogata wrote:
> Hi Martin,
> 
> Thank you for your review.
> 
> Regards,
> Ogata
> 
> "Doerr, Martin" <martin.doerr at sap.com> wrote on 2019/06/06 17:29:07:
> 
>> 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>, "jdk8u-
>> dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
>> Date: 2019/06/06 17:29
>> Subject: [EXTERNAL] RE: [8u-dev, ppc] RFR for non-clean backport of
>> 8185979: PPC64: Implement SHA2 intrinsic
>>
>> 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
>>
>>
> 
>