8283726: x86 intrinsics for compare method in Integer and Long #7975

vamsi-parasa · 2022-03-27T06:15:34Z

Implements x86 intrinsics for compare() method in java.lang.Integer and java.lang.Long.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8283726: x86 intrinsics for compare method in Integer and Long

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/7975/head:pull/7975
$ git checkout pull/7975

Update a local copy of the PR:
$ git checkout pull/7975
$ git pull https://git.openjdk.java.net/jdk pull/7975/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 7975

View PR using the GUI difftool:
$ git pr show -t 7975

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/7975.diff

bridgekeeper · 2022-03-27T06:16:28Z

👋 Welcome back vamsi-parasa! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2022-03-27T06:18:37Z

@vamsi-parasa The following labels will be automatically applied to this pull request:

core-libs
hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

merykitty · 2022-03-27T06:57:58Z

This is both complicated and inefficient, I would suggest building the intrinsic in the IR graph so that the compiler can simplify Integer.compareUnsigned(x, y) < 0 into x u< y. Thanks.

mlbridge · 2022-03-28T05:32:19Z

Webrevs

jatin-bhateja · 2022-03-29T01:39:26Z

src/hotspot/share/classfile/vmIntrinsics.hpp

+  do_intrinsic(_compare_i,                java_lang_Integer,      compare_name,            int2_int_signature,   F_S)   \
+  do_intrinsic(_compare_l,                java_lang_Long,         compare_name,            long2_int_signature,   F_S)  \
+  do_intrinsic(_compareUnsigned_i,        java_lang_Integer,      compare_unsigned_name,   int2_int_signature,   F_S)   \
+   do_name(     compare_unsigned_name,                             "compareUnsigned")                                   \
+  do_intrinsic(_compareUnsigned_l,        java_lang_Long,         compare_unsigned_name,   long2_int_signature,   F_S)  \


Creating these methods as intrinsic will create a box around the underneath comparison logic, this shall prevent any regular constant folding which could have optimized out certain control paths, I would suggest to to handle constant folding for newly added nodes in associated Value routines.

jatin-bhateja · 2022-03-29T01:41:39Z

src/hotspot/share/opto/comparenode.hpp

+class CompareSignedINode : public CompareNode {
+    public:
+    CompareSignedINode(Node* in1, Node* in2) : CompareNode(in1, in2) {}
+    virtual int Opcode() const;
+};
+
+//---------- CompareSignedLNode -----------------------------------------------------
+class CompareSignedLNode : public CompareNode {
+    public:
+    CompareSignedLNode(Node* in1, Node* in2) : CompareNode(in1, in2) {}
+    virtual int Opcode() const;
+};
+
+//---------- CompareUnsignedINode -----------------------------------------------------
+class CompareUnsignedINode : public CompareNode {
+    public:
+    CompareUnsignedINode(Node* in1, Node* in2) : CompareNode(in1, in2) {}
+    virtual int Opcode() const;
+};
+
+//---------- CompareUnsignedLNode -----------------------------------------------------
+class CompareUnsignedLNode : public CompareNode {
+    public:
+    CompareUnsignedLNode(Node* in1, Node* in2) : CompareNode(in1, in2) {}
+    virtual int Opcode() const;
+};


Intent here seems to be to enable further auto-vectorization of newly create IR nodes.

Yes, that is the intention.

src/hotspot/cpu/x86/x86_64.ad

jatin-bhateja · 2022-03-29T02:12:56Z

test/micro/org/openjdk/bench/java/lang/CompareInteger.java

+        for (int i = 0; i < BUFFER_SIZE; i++) {
+            input1[i] = rng.nextInt();
+            if (mode.equals("equal")) {
+                input2[i] = input1[i];
+                continue;
+            }
+            else input2[i] = rng.nextInt();
+
+            if (!mode.equals("mixed")) {
+                boolean doSwap = (mode.equals("lessThanEqual") && input1[i] > input2[i]) ||
+                                (mode.equals("greaterThanEqual") && input1[i] < input2[i]);
+                if (doSwap) {
+                    int tmp = input1[i];
+                    input1[i] = input2[i];
+                    input2[i] = tmp;
+                }
+            }


Logic re-organization suggestion:-

for (int i = 0 ; i < BUFFER_SIZE; i++) { input1[i] = rng.nextLong(); } if (mode.equals("equals") { GRADIANT = 0; } else if (mode.equals("greaterThanEquals")) { GRADIANT = 1; } else { assert mode.equals("lessThanEqual"); GRADIANT = -1; } for(int i = 0 ; i < BUFFER_SIZE; i++) { input2[i] = input1[i] + i*GRADIANT; }

The suggested refactoring is definitely elegant but one rare possibility is overflow due to the addition/subtraction. The swap logic doesn't have that problem.

The suggested refactoring is definitely elegant but one rare possibility is overflow due to the addition/subtraction. The swap logic doesn't have that problem.

Given that BUFFER_SIZE is 1024 can we not circumvent this problem by using rng.nextLong(4096) in initialization loop.

jatin-bhateja · 2022-03-29T02:20:27Z

test/micro/org/openjdk/bench/java/lang/CompareLong.java

+/*
+ * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it


We can unify this benchmark along with integer compare micro.

Sure, will do the unification.

jatin-bhateja · 2022-03-29T02:24:21Z

src/hotspot/cpu/x86/x86_64.ad

+//----------Intrinsics for Compare function------------------------------------
+
+instruct compareSignedI_rReg(rRegI dst, rRegI op1, rRegI op2, rRegI tmp, rFlagsReg cr)
+%{
+  match(Set dst (CompareSignedI op1 op2));


Please also include these patterns in x86_32.ad

Will update x86_32.ad as well.

src/hotspot/cpu/x86/x86_64.ad

vamsi-parasa · 2022-03-29T21:56:18Z

This is both complicated and inefficient, I would suggest building the intrinsic in the IR graph so that the compiler can simplify Integer.compareUnsigned(x, y) < 0 into x u< y. Thanks.

Thank you for the suggestion! This intrinsic uses 1 cmp instruction instead of two and shows ~10% improvement due to better branch prediction. Even without the intrinsic, the compiler is currently able to reduce it to x u< y but is still generating two cmp (unsigned) instructions as Integer.compareUnsigned(x, y) is implemented as x u< y? -1 : (x ==y ? 0 : 1).

merykitty · 2022-03-29T23:26:52Z

@vamsi-parasa But normally the result of the compare methods is not used as a raw integer (it is useless to do so since the methods do not have any promise regarding the value of the result, only its sign). The idiom is to compare the result with 0, such as Integer.compare(x, y) > 0, the compiler can reduce this to x > y (last time I checked it does not do so but in principle this is possible). Your intrinsic prevents the compiler from doing such transformations, hurting the performance of real programs.

Even without the intrinsic, the compiler is currently able to reduce it to x u< y

It is because the compiler can recognise the pattern x + MIN_VALUE < y + MIN_VALUE and transforms it into x u< y. This transformation is fragile however if one of the arguments is in the form x + con, in such cases constant propagation may lead to slight deviations from recognised patterns, defeat the transformations. As a result, it may be justifiable to have a dedicated intrinsic for that since unsigned comparisons are pretty basic operations that are needed for optimal range check performance.

Thanks.

jatin-bhateja · 2022-03-31T07:12:55Z

@vamsi-parasa But normally the result of the compare methods is not used as a raw integer (it is useless to do so since the methods do not have any promise regarding the value of the result, only its sign). The idiom is to compare the result with 0, such as Integer.compare(x, y) > 0, the compiler can reduce this to x > y (last time I checked it does not do so but in principle this is possible). Your intrinsic prevents the compiler from doing such transformations, hurting the performance of real programs.

Even without the intrinsic, the compiler is currently able to reduce it to x u< y

It is because the compiler can recognise the pattern x + MIN_VALUE < y + MIN_VALUE and transforms it into x u< y. This transformation is fragile however if one of the arguments is in the form x + con, in such cases constant propagation may lead to slight deviations from recognised patterns, defeat the transformations. As a result, it may be justifiable to have a dedicated intrinsic for that since unsigned comparisons are pretty basic operations that are needed for optimal range check performance.

Thanks.

I agree, what @merykitty is proposing is to add another transformation on top of newly generated IR nodes which can reduce the emitted JIT sequence, along with this constant operand handling for newly created IR nodes though Value routines will also be useful.

bridgekeeper · 2022-04-28T20:32:20Z

@vamsi-parasa This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

bridgekeeper · 2022-05-26T22:38:28Z

@vamsi-parasa This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

8283726: x86 intrinsics for compare method in Integer and Long

bb86770

openjdk bot added hotspot hotspot-dev@openjdk.org core-libs core-libs-dev@openjdk.org labels Mar 27, 2022

add JMH benchmarks

b0c3314

vamsi-parasa marked this pull request as ready for review March 28, 2022 05:26

openjdk bot added the rfr Pull request is ready for review label Mar 28, 2022

jatin-bhateja reviewed Mar 29, 2022

View reviewed changes

vamsi-parasa added 3 commits March 30, 2022 13:49

Merge branch 'master' of https://git.openjdk.java.net/jdk into cmp

5b38ec1

refactored x86_64.ad code to macro assembly routines

79e4aa5

Merge branch 'openjdk:master' into cmp

95238a2

Merge branch 'openjdk:master' into cmp

1220b04

bridgekeeper bot closed this May 26, 2022

shqking mentioned this pull request Dec 1, 2022

8287925: AArch64: intrinsics for compareUnsigned method in Integer and Long #11383

Closed

3 tasks

8283726: x86 intrinsics for compare method in Integer and Long #7975

8283726: x86 intrinsics for compare method in Integer and Long #7975

Uh oh!

Conversation

vamsi-parasa commented Mar 27, 2022 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewing

Uh oh!

bridgekeeper bot commented Mar 27, 2022

Uh oh!

openjdk bot commented Mar 27, 2022

Uh oh!

merykitty commented Mar 27, 2022

Uh oh!

mlbridge bot commented Mar 28, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

vamsi-parasa commented Mar 29, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

merykitty commented Mar 29, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jatin-bhateja commented Mar 31, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bridgekeeper bot commented Apr 28, 2022

Uh oh!

bridgekeeper bot commented May 26, 2022

Uh oh!

Uh oh!

vamsi-parasa commented Mar 27, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Mar 28, 2022 •

edited

Loading

vamsi-parasa commented Mar 29, 2022 •

edited

Loading

merykitty commented Mar 29, 2022 •

edited

Loading

jatin-bhateja commented Mar 31, 2022 •

edited

Loading