Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8276162: Optimise unsigned comparison pattern #6101

Closed
wants to merge 10 commits into from

Conversation

merykitty
Copy link
Contributor

@merykitty merykitty commented Oct 25, 2021

This patch changes operations in the form x +- Integer.MIN_VALUE <=> y +- Integer.MIN_VALUE, which is a pattern used to do unsigned comparisons, into x u<=> y.

In addition to being basic operations, they may be utilised to implement range checks such as the methods in jdk.internal.util.Preconditions, or in places where the compiler cannot deduce the non-negativeness of the bound as in java.util.ArrayList.

Thank you very much.


Progress

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

Issue

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6101

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

Using diff file

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

@bridgekeeper bridgekeeper bot added the oca label Oct 25, 2021
@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Oct 25, 2021

Hi @merykitty, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user MeryKitty" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

@merykitty
Copy link
Contributor Author

@merykitty merykitty commented Oct 25, 2021

/signed

@bridgekeeper bridgekeeper bot added the oca-verify label Oct 25, 2021
@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Oct 25, 2021

Thank you! Please allow for up to two weeks to process your OCA, although it is usually done within one to two business days. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

@openjdk
Copy link

@openjdk openjdk bot commented Oct 25, 2021

@merykitty The following label will be automatically applied to this pull request:

  • hotspot-compiler

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

@openjdk openjdk bot added the hotspot-compiler label Oct 25, 2021
@bridgekeeper bridgekeeper bot removed oca oca-verify labels Oct 28, 2021
@DamonFool
Copy link
Member

@DamonFool DamonFool commented Oct 29, 2021

It would be better if you can provide a micro benchmark to show us the performance improvement.
Thanks.

@merykitty
Copy link
Contributor Author

@merykitty merykitty commented Oct 29, 2021

I created a simple benchmark, the benchmark is run on Intel i7-7700HQ, the result is as follow:

Before:
Benchmark    Mode  Cnt  Score   Error  Units
App.runInt   avgt   25  3.963 ± 0.181  ns/op
App.runLong  avgt   25  4.431 ± 0.101  ns/op

After:
Benchmark    Mode  Cnt  Score   Error  Units
App.runInt   avgt   25  3.678 ± 0.192  ns/op
App.runLong  avgt   25  3.814 ± 0.085  ns/op

This is the source code of the benchmark:

package io.github.merykitty.simplebenchmark;

import java.io.IOException;
import java.util.concurrent.TimeUnit;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;

@BenchmarkMode(Mode.AverageTime)
@State(Scope.Benchmark)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5)
@Measurement(iterations = 5)
public class App {
    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    public long test(int arg0, int arg1) {
        return arg0 + Integer.MIN_VALUE < arg1 + Integer.MIN_VALUE ? 1 : 0;
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    public long test(long arg0, long arg1) {
        return arg0 + Long.MIN_VALUE < arg1 + Long.MIN_VALUE ? 1 : 0;
    }

    @Benchmark
    public void runInt() {
        test(0, -1);
        test(-1, 0);
    }

    @Benchmark
    public void runLong() {
        test(0L, -1L);
        test(-1L, 0L);
    }

    public static void main( String[] args ) throws IOException {
        org.openjdk.jmh.Main.main(args);
    }
}

Do I need to add the benchmark to the patch? If yes then where should I put it in?

Thank you very much.

@DamonFool
Copy link
Member

@DamonFool DamonFool commented Oct 29, 2021

I created a simple benchmark, the benchmark is run on Intel i7-7700HQ, the result is as follow:

Before:
Benchmark    Mode  Cnt  Score   Error  Units
App.runInt   avgt   25  3.963 ± 0.181  ns/op
App.runLong  avgt   25  4.431 ± 0.101  ns/op

After:
Benchmark    Mode  Cnt  Score   Error  Units
App.runInt   avgt   25  3.678 ± 0.192  ns/op
App.runLong  avgt   25  3.814 ± 0.085  ns/op

This is the source code of the benchmark:

package io.github.merykitty.simplebenchmark;

import java.io.IOException;
import java.util.concurrent.TimeUnit;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;

@BenchmarkMode(Mode.AverageTime)
@State(Scope.Benchmark)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5)
@Measurement(iterations = 5)
public class App {
    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    public long test(int arg0, int arg1) {
        return arg0 + Integer.MIN_VALUE < arg1 + Integer.MIN_VALUE ? 1 : 0;
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    public long test(long arg0, long arg1) {
        return arg0 + Long.MIN_VALUE < arg1 + Long.MIN_VALUE ? 1 : 0;
    }

    @Benchmark
    public void runInt() {
        test(0, -1);
        test(-1, 0);
    }

    @Benchmark
    public void runLong() {
        test(0L, -1L);
        test(-1L, 0L);
    }

    public static void main( String[] args ) throws IOException {
        org.openjdk.jmh.Main.main(args);
    }
}

Do I need to add the benchmark to the patch? If yes then where should I put it in?

Thank you very much.

I think you can put it under test/micro/org/openjdk/bench/vm/compiler with a more meaningful class name.
Please note that the jcheck failed in your PR, which seems to prevent the RFR email from sending out.

@merykitty
Copy link
Contributor Author

@merykitty merykitty commented Oct 29, 2021

I have just pushed the microbenchmark, I am not sure what to put in the copyright line, though.

The check failure seems to be due to this PR does not refer to an existing issue.

Thank you very much.

@DamonFool
Copy link
Member

@DamonFool DamonFool commented Oct 29, 2021

I have just pushed the microbenchmark, I am not sure what to put in the copyright line, though.

The check failure seems to be due to this PR does not refer to an existing issue.

Thank you very much.

Filed https://bugs.openjdk.java.net/browse/JDK-8276162 for you.
Thanks.

@merykitty merykitty changed the title Optimise unsigned comparison pattern 8276162: Optimise unsigned comparison pattern Oct 29, 2021
@openjdk openjdk bot added the rfr label Oct 29, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Oct 29, 2021

@merykitty
Copy link
Contributor Author

@merykitty merykitty commented Nov 10, 2021

Hi, may someone take a look at this PR, please.
Thank you very much.

src/hotspot/share/opto/subnode.cpp Outdated Show resolved Hide resolved
src/hotspot/share/opto/subnode.cpp Outdated Show resolved Hide resolved
src/hotspot/share/opto/subnode.cpp Outdated Show resolved Hide resolved
src/hotspot/share/opto/subnode.cpp Outdated Show resolved Hide resolved
const int cmp1_op = cmp1->Opcode();
const int cmp2_op = cmp2->Opcode();

// Change x +- Integer.MIN_VALUE <=> y +- Integer.MIN_VALUE into x u<=> y
Copy link
Contributor

@vnkozlov vnkozlov Nov 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment should include cmp2_op == Op_ConI case.
Also it is not clear from comment and code if different operations are allowed on both side: x - MIN_INT <= y + MIN_INT

(cmp1_op == Op_AddI || cmp1_op == Op_SubI) &&
phase->type(cmp1->in(2)) == TypeInt::MIN) {
if (cmp2_op == Op_ConI) {
Node *ncmp2 = phase->intcon(java_add(cmp2->get_int(), min_jint));
Copy link
Contributor

@vnkozlov vnkozlov Nov 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if cmp1_op == Op_SubI ?

Copy link
Contributor Author

@merykitty merykitty Nov 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since x + MIN_VALUE == x - MIN_VALUE, the operation is the same with addition and subtraction operations. However, I realised that x - MIN_VALUE is idealised into x + MIN_VALUE beforehand, so I have removed the check for Op_SubI here.

Node *ncmp2 = phase->intcon(java_add(cmp2->get_int(), min_jint));
Node *ncmp = phase->transform(new CmpUNode(cmp1->in(1), ncmp2));
return new BoolNode(ncmp, _test._test);
} else if ((cmp2_op == Op_AddI || cmp2_op == Op_SubI) &&
Copy link
Contributor

@vnkozlov vnkozlov Nov 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again the question about mismatching cmp1_op and cmp2_op.

Copy link
Member

@TobiHartmann TobiHartmann left a comment

Given that there is Integer/Long.compareUnsigned using this idiom, it seems reasonable to optimize. Some general comments:

  • Your benchmark does not cover all the cases you are optimizing. Maybe you should also add the Integer.compareUnsigned variants.
  • You need a correctness test as well, ideally using the IR verification framework to also verify that the optimizations are actually performed.

@@ -1529,10 +1531,43 @@ Node *BoolNode::Ideal(PhaseGVN *phase, bool can_reshape) {
}
}

// Change x + Integer.MIN_VALUE <=> y + Integer.MIN_VALUE into x u<=> y
Copy link
Member

@TobiHartmann TobiHartmann Nov 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The <=> in the comment is confusing because it usually denotes logical equality. Also, you are only handling < and > below. What about the other variants? Shouldn't they be canonicalized in idealize_test (see ifnode.cpp)?

I would recommend making it explicit in the comment and use brackets for readability:

// Change (x + Integer.MIN_VALUE < y + Integer.MIN_VALUE) into (x u< y) and
//        (x + Integer.MIN_VALUE > y + Integer.MIN_VALUE) into (x u> y).

Copy link
Contributor Author

@merykitty merykitty Nov 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added eq and ne to the transformation, leaving the comment simply as cmp (add X min_jint) (add Y min_jint).

return new BoolNode(ncmp, _test._test);
} else if (cmp2_op == Op_AddI &&
phase->type(cmp2->in(2)) == TypeInt::MIN) {
Node *ncmp = phase->transform(new CmpUNode(cmp1->in(1), cmp2->in(1)));
Copy link
Member

@TobiHartmann TobiHartmann Nov 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Node *ncmp -> Node* ncmp

Copy link
Contributor Author

@merykitty merykitty Nov 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, sir.

Copy link
Contributor

@vnkozlov vnkozlov left a comment

Thank you for addressing my comments.

I am tentatively approve these changes leaving final approval and testing to @TobiHartmann

@openjdk
Copy link

@openjdk openjdk bot commented Nov 12, 2021

⚠️ @merykitty the full name on your profile does not match the author name in this pull requests' HEAD commit. If this pull request gets integrated then the author name from this pull requests' HEAD commit will be used for the resulting commit. If you wish to push a new commit with a different author name, then please run the following commands in a local repository of your personal fork:

$ git checkout compareUnsignedMatcher
$ git commit -c user.name='Preferred Full Name' --allow-empty -m 'Update full name'
$ git push

@openjdk
Copy link

@openjdk openjdk bot commented Nov 12, 2021

@merykitty This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8276162: Optimise unsigned comparison pattern

Reviewed-by: thartmann, kvn

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 297 new commits pushed to the master branch:

  • 9a9a157: 8276905: Use appropriate macosx_version_minimum value while compiling metal shaders
  • 7906eb0: 8277119: Add asserts in GenericTaskQueueSet methods
  • 1c45c8a: 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module
  • c06df25: 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent
  • 9629627: 8274163: Use String.equals instead of String.compareTo in jdk.jcmd
  • 0bc2683: 8274190: Use String.equals instead of String.compareTo in jdk.internal.jvmstat
  • a9cb8bd: 8274168: Avoid String.compareTo == 0 to check String equality in java.management
  • 20f3872: 8274261: Use enhanced-for instead of plain 'for' in jdk.jcmd
  • b8d33a2: 8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes
  • 1d79cfd: 8276229: Stop allowing implicit updates in G1BlockOffsetTable
  • ... and 287 more: https://git.openjdk.java.net/jdk/compare/5bbe4cae8746765d2ce965b06fd1e5cf512326ae...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@TobiHartmann, @vnkozlov) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready label Nov 12, 2021
@merykitty
Copy link
Contributor Author

@merykitty merykitty commented Nov 13, 2021

@TobiHartmann Thank you very much for the review, I have added the correctness test as well as revised the microbenchmark to cover all the situations including calling to [Integer/Long].compareUnsigned. The result of the benchmark is as follow:

Before:
Benchmark                         Mode  Cnt     Score    Error  Units
UnsignedComparison.intConDirect   avgt   10   927.540 ± 19.142  ns/op
UnsignedComparison.intConLibGT    avgt   10   916.753 ±  4.502  ns/op
UnsignedComparison.intConLibLT    avgt   10   927.911 ± 15.027  ns/op
UnsignedComparison.intVarDirect   avgt   10  1005.895 ± 14.030  ns/op
UnsignedComparison.intVarLibGT    avgt   10   999.216 ±  1.528  ns/op
UnsignedComparison.intVarLibLT    avgt   10  1000.501 ±  4.117  ns/op
UnsignedComparison.longConDirect  avgt   10  1082.950 ±  8.166  ns/op
UnsignedComparison.longConLibGT   avgt   10  1081.340 ±  6.883  ns/op
UnsignedComparison.longConLibLT   avgt   10  1079.599 ±  4.229  ns/op
UnsignedComparison.longVarDirect  avgt   10  1131.605 ± 76.268  ns/op
UnsignedComparison.longVarLibGT   avgt   10  1180.006 ±  7.018  ns/op
UnsignedComparison.longVarLibLT   avgt   10  1178.463 ±  0.809  ns/op

After:
Benchmark                         Mode  Cnt    Score    Error  Units
UnsignedComparison.intConDirect   avgt   10  740.951 ±  5.020  ns/op
UnsignedComparison.intConLibGT    avgt   10  808.425 ±  2.989  ns/op
UnsignedComparison.intConLibLT    avgt   10  740.029 ±  1.332  ns/op
UnsignedComparison.intVarDirect   avgt   10  911.489 ±  4.700  ns/op
UnsignedComparison.intVarLibGT    avgt   10  979.338 ±  8.130  ns/op
UnsignedComparison.intVarLibLT    avgt   10  910.429 ±  3.452  ns/op
UnsignedComparison.longConDirect  avgt   10  750.174 ±  5.915  ns/op
UnsignedComparison.longConLibGT   avgt   10  828.144 ± 53.091  ns/op
UnsignedComparison.longConLibLT   avgt   10  771.493 ± 52.902  ns/op
UnsignedComparison.longVarDirect  avgt   10  882.139 ±  2.091  ns/op
UnsignedComparison.longVarLibGT   avgt   10  952.862 ± 10.248  ns/op
UnsignedComparison.longVarLibLT   avgt   10  881.623 ±  1.895  ns/op

Copy link
Member

@TobiHartmann TobiHartmann left a comment

Nice IR verification test. Your changes look good to me and all testing passed.

@merykitty
Copy link
Contributor Author

@merykitty merykitty commented Nov 16, 2021

/integrate

@openjdk openjdk bot added the sponsor label Nov 16, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Nov 16, 2021

@merykitty
Your change (at version 92e92cf) is now ready to be sponsored by a Committer.

@merykitty
Copy link
Contributor Author

@merykitty merykitty commented Nov 16, 2021

Thank @vnkozlov and @TobiHartmann for your reviews and suggestions, thank @DamonFool for your initial supports.
May I have this PR sponsored, please?

Thank you very much.

@TobiHartmann
Copy link
Member

@TobiHartmann TobiHartmann commented Nov 16, 2021

/sponsor

@openjdk
Copy link

@openjdk openjdk bot commented Nov 16, 2021

Going to push as commit f3eb501.
Since your change was applied there have been 297 commits pushed to the master branch:

  • 9a9a157: 8276905: Use appropriate macosx_version_minimum value while compiling metal shaders
  • 7906eb0: 8277119: Add asserts in GenericTaskQueueSet methods
  • 1c45c8a: 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module
  • c06df25: 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent
  • 9629627: 8274163: Use String.equals instead of String.compareTo in jdk.jcmd
  • 0bc2683: 8274190: Use String.equals instead of String.compareTo in jdk.internal.jvmstat
  • a9cb8bd: 8274168: Avoid String.compareTo == 0 to check String equality in java.management
  • 20f3872: 8274261: Use enhanced-for instead of plain 'for' in jdk.jcmd
  • b8d33a2: 8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes
  • 1d79cfd: 8276229: Stop allowing implicit updates in G1BlockOffsetTable
  • ... and 287 more: https://git.openjdk.java.net/jdk/compare/5bbe4cae8746765d2ce965b06fd1e5cf512326ae...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Nov 16, 2021
@openjdk openjdk bot added integrated and removed ready rfr sponsor labels Nov 16, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Nov 16, 2021

@TobiHartmann @merykitty Pushed as commit f3eb501.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@TobiHartmann
Copy link
Member

@TobiHartmann TobiHartmann commented Nov 17, 2021

This introduced a regression on 32-bit x86, @merykitty could you please have a look?
JDK-8277324

@TobiHartmann
Copy link
Member

@TobiHartmann TobiHartmann commented Nov 17, 2021

The problem is missing match rules on x86-32: #6427

@merykitty merykitty deleted the compareUnsignedMatcher branch Nov 30, 2021
@DamonFool
Copy link
Member

@DamonFool DamonFool commented Dec 2, 2021

This introduced a regression on 32-bit x86 for Vector API tests, could someone help to review it?
#6533
Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-compiler integrated
4 participants