JDK-8212043 : AArch64: Add floating-point Math.min/max intrinsics
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2018-10-11
  • Updated: 2022-02-06
  • Resolved: 2018-12-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13
11.0.11Fixed 13 b01Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
We could add intrinsics of below 4 math methods to benefit their performance, at least for AArch64 platform.
1) public static float min(float a, float b)
2) public static float max(float a, float b)
3) public static double min(double a, double b)
4) public static double max(double a, double b)
 
Java code of "Math.max(double a, double b)":
1489     public static double max(double a, double b) {
1490         if (a != a)
1491             return a;   // a is NaN
1492         if ((a == 0.0d) &&
1493             (b == 0.0d) &&
1494             (Double.doubleToRawLongBits(a) == negativeZeroDoubleBits)) {
1495             // Raw conversion ok since NaN can't map to -0.0.
1496             return b;
1497         }
1498         return (a >= b) ? a : b;
1499     }
 
Below is the description of this method in Java API doc. The behaviors of the other 3 methods are similar.
"Returns the greater of two double values. That is, the result is the argument closer to positive infinity. If the arguments have the same value, the result is that same value. If either value is NaN, then the result is NaN. Unlike the numerical comparison operators, this method considers negative zero to be strictly smaller than positive zero. If one argument is positive zero and the other negative zero, the result is positive zero."
i.e.
Math.max(2.0, -1.5) == 2.0
Math.max(0.0, 0.0) == 0.0
Math.max(0.0, -0.0) == 0.0  // min is -0.0
Math.max(Double.POSITIVE_INFINITY, 2.0) == Double.POSITIVE_INFINITY
Math.max(Double.NEGATIVE_INFINITY, 2.0) == 2.0
Math.max(1.0, Double.NaN) == Double.NaN
Math.max(Double.NaN, Double.NaN) == Double.NaN
 
In AArch64 instruction set, the floating point instructions fmin and fmax have exactly the same behavior to the APIs above. So these intrinsics can be done in one single instruction on AArch64.
Comments
I believe JDK-8226627 should be backported to 11u, too.
28-03-2021

Fix Request (11u): Backporting this patch improves performance on aarch64. Original patch does not applies cleanly and requires minor adjustments. Backport for post-fix JDK-8215687 is also included in the webrev. Testing: tier1, tier2; compiler/graalunit with Graal on - CheckGraalIntrinsics fails because of ECB intrinsics but not not because of min/max. The change is declaration of new intrinsics in shared code, and single instruction implementations for aarch64, also additive. It was integrated in early JDK 13. So the risk is low. 11u RFR: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-January/004682.html (R) https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-January/004737.html
28-01-2021

Per review 11u backport has been split into 3 pieces (JDK-8212043, JDK-8215687, JDK-8218550): Updated webrev for this rfe: http://cr.openjdk.java.net/~dchuyko/8212043/webrev.11u.01/
25-01-2021

I don't know how Graal manages its up/down syncs but as this caused a breakage in the OpenJDK testing we would like a fix in the OpenJDK repo ASAP - as per JDK-8215317. Thanks.
20-12-2018

Hi David, Sorry for the inconvenience. I know this change would break the CheckGraalIntrinsics test and have a patch to fix. But I supposed this fix should be pushed to Graal repo in github as this change is target for JDK13 so the failure will be fixed after the next Graal sync. Please let me know if what I was thinking is wrong.
20-12-2018

Pengfei, This is the PPC64 change David is referring to, for some background, if that helps: https://bugs.openjdk.java.net/browse/JDK-8215317 Some useful comments from Vladimir and David in there.
19-12-2018

This issue changed shared code in various locations that has much wider impact than on Aarch64. This has broken a Graal test (as did the supposed PPC64 intrinsics last week.)!
19-12-2018

URL: http://hg.openjdk.java.net/jdk/jdk/rev/f15af1e2c683 User: adinn Date: 2018-12-19 10:10:28 +0000
19-12-2018