8273454: C2: Transform (-a)(-b) into ab #5403

zhengyu123 · 2021-09-07T22:40:50Z

The transformation reduce instructions in generated code.

x86_64:

Before:

  0x00007fb92c78b3ac:   neg    %esi
  0x00007fb92c78b3ae:   neg    %edx
  0x00007fb92c78b3b0:   mov    %esi,%eax
  0x00007fb92c78b3b2:   imul   %edx,%eax                    ;*imul {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestSub::runSub@4 (line 9)

After:

                                                           ; - TestSub::runSub@-1 (line 9)
  0x00007fc8c05b74ac:   mov    %esi,%eax
  0x00007fc8c05b74ae:   imul   %edx,%eax                    ;*imul {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestSub::runSub@4 (line 9)

AArch64:

Before:

 0x0000ffff814b4a70:   neg     w11, w1
 0x0000ffff814b4a74:   mneg    w0, w2, w11                 ;*imul {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestSub::runSub@4 (line 9)

After:

 0x0000ffff794a67f0:   mul     w0, w1, w2                  ;*imul {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestSub::runSub@4 (line 9)

Progress

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

Issue

JDK-8273454: C2: Transform (-a)(-b) into ab

Reviewers

Tobias Hartmann (@TobiHartmann - Reviewer)
Eric Liu (@theRealELiu - Author) ⚠️ Review applies to 71aa6ac
Christian Hagedorn (@chhagedorn - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5403

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

Using diff file

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

bridgekeeper · 2021-09-07T22:40:55Z

👋 Welcome back zgu! 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 · 2021-09-07T22:43:23Z

@zhengyu123 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.

mlbridge · 2021-09-07T22:48:28Z

Webrevs

e1iu · 2021-09-08T04:23:19Z

src/hotspot/share/opto/mulnode.cpp

+  Node *in1 = in(1);
+  Node *in2 = in(2);
+  if (in1->Opcode() == Op_SubI && in2->Opcode() == Op_SubI) {
+    Node* n11 = in1->in(1);
+    Node* n21 = in2->in(1);
+    if (phase->type(n11)->higher_equal(TypeInt::ZERO) &&
+        phase->type(n21)->higher_equal(TypeInt::ZERO)) {


I was thinking if it's a good idea to move these code into MulNode, as they were actually much the same with MulLNode.

I wonder that too, so is the rest of MulINode/MulLNode::Ideal() code (and many other places). I am not sure how to workaround the different types, any suggestions?

Just a dogfood, but it works. https://gist.github.com/theRealELiu/328d62157975b1f20e3626b3ef747eb4

Too much abstraction makes the code hard to read. One needs to check the concrete class to identify what the code exactly is, E.g. In my patch, add_id() may be TypeInt::ZERO or TypeLong::Zero, even TypeD::ZERO. So I'm not sure if it's a good idea. Is there any guidelines to this issue, try to abstract them or make the readability in the first place? @TobiHartmann

Yes, I would also prefer to move the optimization into MulNode::Ideal. @theRealELiu's patch is good but can be further improved by modifying the node inputs instead of returning a new node (similar to the other optimizations in MulNode::Ideal).

Also, Type::is_zero_type can be used to detect 0 and instead of checking the opcodes, Node::is_Sub should be used.

Nice! Thanks, I will make changes accordingly.

TobiHartmann · 2021-09-09T07:17:28Z

src/hotspot/share/opto/mulnode.cpp

+  Node *in1 = in(1);
+  Node *in2 = in(2);
+  if (in1->Opcode() == Op_SubI && in2->Opcode() == Op_SubI) {
+    Node* n11 = in1->in(1);
+    Node* n21 = in2->in(1);
+    if (phase->type(n11)->higher_equal(TypeInt::ZERO) &&
+        phase->type(n21)->higher_equal(TypeInt::ZERO)) {


Yes, I would also prefer to move the optimization into MulNode::Ideal. @theRealELiu's patch is good but can be further improved by modifying the node inputs instead of returning a new node (similar to the other optimizations in MulNode::Ideal).

TobiHartmann · 2021-09-09T07:19:13Z

src/hotspot/share/opto/mulnode.cpp

+  Node *in1 = in(1);
+  Node *in2 = in(2);
+  if (in1->Opcode() == Op_SubI && in2->Opcode() == Op_SubI) {
+    Node* n11 = in1->in(1);
+    Node* n21 = in2->in(1);
+    if (phase->type(n11)->higher_equal(TypeInt::ZERO) &&
+        phase->type(n21)->higher_equal(TypeInt::ZERO)) {


Also, Type::is_zero_type can be used to detect 0 and instead of checking the opcodes, Node::is_Sub should be used.

TobiHartmann · 2021-09-09T07:24:11Z

test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

+        }
+    }
+
+    private static final long[][] longParams = {


Similar to https://git.openjdk.java.net/jdk/pull/5266, I would prefer random values for better coverage.

TobiHartmann · 2021-09-09T07:24:37Z

test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

+
+/**
+ * @test
+ * @bug 8270366


The bug number is incorrect.

TobiHartmann · 2021-09-09T07:31:20Z

test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

+        for (int index = 0; index < intParams.length; index ++) {
+            int result = intTest(intParams[index][0], intParams[index][1]);
+            for (int i = 0; i < 20_000; i++) {
+                if (result != intTest(intParams[index][0], intParams[index][1])) {


After some warmup iterations, intTest will be C2 compiled and you are then comparing outputs of the same compiled method. I.e., if there's a bug in the C2 optimization, the test might not catch it. What you should do instead, is to compare the output of the C2 compiled method to the expected value (which is a * b in this case).

You should also prevent inlining of intTest.

The test you added with JDK-8270366 has the same problem.

TobiHartmann · 2021-09-09T13:45:24Z

src/hotspot/share/opto/mulnode.cpp

+    Node* n21 = in2->in(1);
+    if (phase->type(n11)->is_zero_type() &&
+        phase->type(n21)->is_zero_type()) {
+      return make(in1->in(2), in2->in(2));


Why do you need to create a new node? Can't you simply update the inputs like the code below does?

Sorry, I missed your early comment. Fixed.

e1iu · 2021-09-10T02:37:55Z

test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

+    }
+
+    private static void testInt(int a, int b) {
+        int expected = (-a) * (-b);


Are you sure about this is the expected value? As the method has been invoked 2000 times, I think it would be compiled by c2.

The default CompileThreshold is 10K when tiered compilation is disabled, which is the case here, so there is no risk.

But why don't you compute expected as a * b?

I would prefer to keep as it is to match testxxx() functions. I think it articulates that JIT-ed result matches interpreter's.

e1iu · 2021-09-10T02:53:45Z

test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

+    private static void testLong(long a, long b) {
+        long expected = (-a) * (-b);
+        for (int i = 0; i < 20_000; i++) {
+            if (expected != test(a, b)) {
+                throw new RuntimeException("Incorrect result.");
+            }
+        }
+    }


How about calculating the expected value outside the iteration to avoid it to be compiled？

private static void testLong() { for (int i = 0; i < 20_000; i++) { long a = random.nextLong(); long b = random.nextLong(); long expected = (-a) * (-b); if (expected != test(a, b)) { throw new RuntimeException("Incorrect result."); } } }

And just call this method once in main to prevent it from being too hot.

e1iu

LGTM

zhengyu123 · 2021-09-13T19:07:33Z

LGTM

Thanks, @theRealELiu

TobiHartmann · 2021-09-14T06:49:50Z

src/hotspot/share/opto/mulnode.cpp

  Node *in1 = in(1);
  Node *in2 = in(2);
+  if (in1->is_Sub() && in2->is_Sub()) {
+    Node* n11 = in1->in(1);


For consistency with below code, I would name the local in11 or simply use phase->type(in1->in(1)) because it's the only user.

TobiHartmann · 2021-09-14T06:53:39Z

test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

+import java.util.Random;
+
+public class TestNegMultiply {
+    private static Random random = new Random();


You should use Utils.getRandomInstance() from jdk.test.lib.Utils to ensure that the seed is printed for reproducibility. You can check other tests for an example.

TobiHartmann · 2021-09-14T06:54:48Z

test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

+
+/**
+ * @test
+ * @bug 8273454


The test needs * @key randomness

TobiHartmann · 2021-09-14T06:58:57Z

test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

+    }
+
+    private static void testInt(int a, int b) {
+        int expected = (-a) * (-b);


But why don't you compute expected as a * b?

TobiHartmann · 2021-09-14T07:05:40Z

test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

+
+    private static void testInt(int a, int b) {
+        int expected = (-a) * (-b);
+        for (int i = 0; i < 20_000; i++) {


Why do you need a second loop in here? It's sufficient to set TEST_COUNT high enough to trigger compilation. I would suggest something like this:

private static int testInt(int a, int b) { return (-a) * (-b); } private static void runIntTests() { for (int i = 0; i < TEST_COUNT; i++) { int a = random.nextInt(); int b = random.nextInt(); int res = testInt(a, b); Asserts.assertEQ(a * b, res); } }

And then run with -XX:CompileCommand=dontinline,TestNegMultiply::test*. No need to disable OnStackReplacement.

The inner loop ensures that all tests hit JIT-ed version. If the transformation is broken, I would prefer the test fails for the very first iteration, instead of somewhere in the middle.

I refactored the code to remove inner loop.

Also, fixed command option.

You can't control the iteration in which the test would fail if there's a bug in C2 (it could only fail for some random values). Therefore, you could as well use random values for the warmup and simply increase TEST_COUNT to ensure that C2 compilation is triggered and we run a reasonable amount of iterations with C2 compiled code.

Your newest version of the test now has the problem that OSR compilation might C2 compile the computation of the expected value and then you are comparing the output of a C2 compiled method to a C2 compiled method instead of the interpreter. You have the following options:

Compute the expected value as a * b. In that case it's fine if the computation is C2 compiled as well.

Prevent compilation of the run* methods (either by disabling OSR compilation or by completely disabling compilation of these methods)

And sorry for being picky here but I would like to keep tests as simple as possible :)

Fixed according to you comments.

I really appreciate you suggestions, thanks!

TobiHartmann

Thanks for making these changes, looks good to me.

openjdk · 2021-09-17T07:44:27Z

@zhengyu123 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:

8273454: C2: Transform (-a)*(-b) into a*b

Reviewed-by: thartmann, eliu, chagedorn

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 117 new commits pushed to the master branch:

1890d85: 8273872: ZGC: Explicitly use 2M large pages
54b4567: 8273880: Zero: Print warnings when unsupported intrinsics are enabled
e07ab82: 8273408: java.lang.AssertionError: typeSig ERROR on generated class property of record
8c022e2: 8270434: JDI+UT: Unexpected event in JDI tests
b982904: 8271073: Improve testing with VM option VerifyArchivedFields
bc48a0a: 8273902: Memory leak in OopStorage due to bug in OopHandle::release()
9c5441c: 8271569: Clean up the use of CDS constants and field offsets
12fa707: 8261941: Use ClassLoader for unregistered classes during -Xshare:dump
7e92abe: 8273710: Remove redundant stream() call before forEach in jdk.jdeps
59b2478: 8273659: Replay compilation crashes with SIGSEGV since 8271911
... and 107 more: https://git.openjdk.java.net/jdk/compare/267c61a16a916e35762e8df5737ec74b06defae8...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.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

chhagedorn

Looks good!

zhengyu123 · 2021-09-18T23:09:58Z

@TobiHartmann @chhagedorn Thanks!

zhengyu123 · 2021-09-18T23:10:06Z

/integrate

openjdk · 2021-09-18T23:11:22Z

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

bb9d142: 8273958: gtest/MetaspaceGtests executes unnecessary tests in debug builds
2a2e919: 8273685: Remove jtreg tag manual=yesno for java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction
8302061: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms
2f8c221: 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark
17f7a45: 8273913: Problem list some headful client jtreg tests that fail on macOS 12
27d747a: 8273877: os::unsetenv unused
35f6f1d: 8273808: Cleanup AddFontsToX11FontPath
1890d85: 8273872: ZGC: Explicitly use 2M large pages
54b4567: 8273880: Zero: Print warnings when unsupported intrinsics are enabled
e07ab82: 8273408: java.lang.AssertionError: typeSig ERROR on generated class property of record
... and 114 more: https://git.openjdk.java.net/jdk/compare/267c61a16a916e35762e8df5737ec74b06defae8...master

Your commit was automatically rebased without conflicts.

openjdk · 2021-09-18T23:11:37Z

@zhengyu123 Pushed as commit 7c9868c.

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

Zhengyu Gu added 3 commits September 6, 2021 09:54

v0

4c1e90a

v1

1ed1d7e

Merge branch 'master' into JDK-8273454-neg-mul

b0761b1

openjdk bot added the rfr Pull request is ready for review label Sep 7, 2021

openjdk bot added the hotspot-compiler hotspot-compiler-dev@openjdk.org label Sep 7, 2021

Fix test

c55a327

e1iu reviewed Sep 8, 2021

View reviewed changes

TobiHartmann suggested changes Sep 9, 2021

View reviewed changes

Zhengyu Gu added 3 commits September 9, 2021 09:17

@theRealELiu and @TobiHartmann's comments

be01f17

Merge branch 'master' into JDK-8273454-neg-mul

28d123f

Spacing

8f7f241

TobiHartmann suggested changes Sep 9, 2021

View reviewed changes

Fix node in place instead of creating new node

71aa6ac

e1iu reviewed Sep 10, 2021

View reviewed changes

e1iu approved these changes Sep 11, 2021

View reviewed changes

TobiHartmann suggested changes Sep 14, 2021

View reviewed changes

@TobiHartmann's comments

f9d7d61

openjdk bot removed the rfr Pull request is ready for review label Sep 15, 2021

Trailing space

3f3eeb0

openjdk bot added the rfr Pull request is ready for review label Sep 15, 2021

@TobiHartmann's comments

57d1ecf

TobiHartmann approved these changes Sep 17, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Sep 17, 2021

chhagedorn approved these changes Sep 17, 2021

View reviewed changes

openjdk bot closed this Sep 18, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Sep 18, 2021

8273454: C2: Transform (-a)*(-b) into a*b #5403

8273454: C2: Transform (-a)*(-b) into a*b #5403

Uh oh!

Conversation

zhengyu123 commented Sep 7, 2021 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

x86_64:

AArch64:

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Sep 7, 2021

Uh oh!

openjdk bot commented Sep 7, 2021

Uh oh!

mlbridge bot commented Sep 7, 2021 • 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!

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!

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!

e1iu Sep 10, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

e1iu left a comment

Choose a reason for hiding this comment

Uh oh!

zhengyu123 commented Sep 13, 2021

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!

Choose a reason for hiding this comment

Uh oh!

8273454: C2: Transform (-a)(-b) into ab #5403

8273454: C2: Transform (-a)(-b) into ab #5403

zhengyu123 commented Sep 7, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Sep 7, 2021 •

edited

Loading

e1iu Sep 10, 2021 •

edited

Loading

zhengyu123 Sep 15, 2021 •

edited

Loading

openjdk bot commented Sep 17, 2021 •

edited

Loading