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

8270366: C2: Add associative rule to add/sub node #4765

Closed
wants to merge 7 commits into from

Conversation

zhengyu123
Copy link
Contributor

@zhengyu123 zhengyu123 commented Jul 13, 2021

Please review this small patch that add associative rule to add/sub node, that eliminates a multiply instruction.

e.g.

private static int assocInt(int a, int b, int c) {
  return a * c + b * c;
}

x86_64:
Before:

  0x00007fda1506152c:   imul   %ecx,%esi
  0x00007fda1506152f:   imul   %ecx,%edx
  0x00007fda15061532:   mov    %esi,%eax
  0x00007fda15061534:   add    %edx,%eax                    ;*iadd {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestAssoc::assocInt@6 (line 9)

After:

  0x00007fc1c078d52c:   add    %edx,%esi
  0x00007fc1c078d52e:   mov    %ecx,%eax
  0x00007fc1c078d530:   imul   %esi,%eax                    ;*iadd {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestAssoc::assocInt@6 (line 9)

Progress

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

Issue

  • JDK-8270366: C2: Add associative rule to add/sub node

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4765

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

Using diff file

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Jul 13, 2021

👋 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 openjdk bot added the rfr label Jul 13, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jul 13, 2021

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

@openjdk openjdk bot added the hotspot-compiler label Jul 13, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Jul 13, 2021

Webrevs

@adinn
Copy link
Contributor

@adinn adinn commented Jul 13, 2021

Hi Zhengyu,

It looks like you are missing a case for both long and int. Your code looks for these patterns:

a*b+a*c --> a*(b+c)
a*b+b*c --> b*(a+c)
a*c+b*c --> (a+b)*c

So you are not transforming this this case

a*b+c*a -> a*(b+c)

@dean-long
Copy link
Member

@dean-long dean-long commented Jul 13, 2021

Can this rule cause the JIT to compute different results than the interpreter if there is integer overflow? Does the spec allow that?

@vnkozlov
Copy link
Contributor

@vnkozlov vnkozlov commented Jul 14, 2021

@jddarcy may know the answer.

@adinn
Copy link
Contributor

@adinn adinn commented Jul 14, 2021

Can this rule cause the JIT to compute different results than the interpreter if there is integer overflow?

I don't believe so.

It should obvious that unsigned arithmetic will always give the same result for any order of computation. Why? Well, if we compute the result for a sequence of n-bit operations in an unlimited bit field we can be sure the results are order independent because of the associativity law. Setting and clearing of higher bits because of overflow beyond n-bits will not change the result that appears in the low n bits.

For signed arithmetic all we need to note is that for every signed n-bit operation that overflows (or underflows) there is an equivalent unsigned operation in 2n bits that has the same bottom n-bits plus some extra non-zero bits in the top n bits. So, for any chain of k signed operations there will be an equivalent chain of unsigned operations in at most kn bits which has the same low n bits. Re-ordering the unsigned operations would produce the same unsigned result which guarantees that an equivalent re-ordering of the signed operations will produce the same signed value in the low n bits.

@zhengyu123
Copy link
Contributor Author

@zhengyu123 zhengyu123 commented Jul 14, 2021

Hi Zhengyu,

It looks like you are missing a case for both long and int. Your code looks for these patterns:

a*b+a*c --> a*(b+c)
a*b+b*c --> b*(a+c)
a*c+b*c --> (a+b)*c

So you are not transforming this this case

a*b+c*a -> a*(b+c)

@zhengyu123 zhengyu123 closed this Jul 14, 2021
@zhengyu123 zhengyu123 reopened this Jul 14, 2021
@zhengyu123
Copy link
Contributor Author

@zhengyu123 zhengyu123 commented Jul 14, 2021

Hi Zhengyu,

It looks like you are missing a case for both long and int. Your code looks for these patterns:

a*b+a*c --> a*(b+c)
a*b+b*c --> b*(a+c)
a*c+b*c --> (a+b)*c

So you are not transforming this this case

a*b+c*a -> a*(b+c)

Thanks, Andrew.

Updated.

@zhengyu123
Copy link
Contributor Author

@zhengyu123 zhengyu123 commented Jul 14, 2021

Can this rule cause the JIT to compute different results than the interpreter if there is integer overflow? Does the spec allow that?

Based on [https://www.agner.org/optimize/optimizing_cpp.pdf](Optimizing software in C++), this optimization is implemented in all 4 compilers (GNU, Clang, Microsoft and Intel) author investigated.

For example:

long mask(long a, long b, long c) {
    return a*b + a*c ;
}

GNU/Clang:

 lea    rax,[rdx+rsi*1]
 imul   rax,rdi

MSVC:

lea     eax, DWORD PTR [rdx+r8]
imul    eax, ecx

@vnkozlov
Copy link
Contributor

@vnkozlov vnkozlov commented Jul 14, 2021

https://docs.oracle.com/javase/specs/jls/se16/html/jls-15.html#jls-15.17.1

If an integer multiplication overflows, then the result is the low-order bits of the mathematical product as represented in some sufficiently large two's-complement format. As a result, if overflow occurs, then the sign of the result may not be the same as the sign of the mathematical product of the two operand values.

I am interpreting this as using long arithmetic for integer overflow and taking low 32-bits of result. In this sense suggested optimization is legal.

But we may have bugs in VM. I suggest to add a regression test to compare golden (from Interpreter) values with results from optimized compiled code for all interesting/corner cases.

@chhagedorn
Copy link
Member

@chhagedorn chhagedorn commented Jul 14, 2021

This RFE would also be well suited for using the new IR framework to create an IR test to verify the new IR transformations.

@zhengyu123
Copy link
Contributor Author

@zhengyu123 zhengyu123 commented Jul 14, 2021

https://docs.oracle.com/javase/specs/jls/se16/html/jls-15.html#jls-15.17.1

If an integer multiplication overflows, then the result is the low-order bits of the mathematical product as represented in some sufficiently large two's-complement format. As a result, if overflow occurs, then the sign of the result may not be the same as the sign of the mathematical product of the two operand values.

I am interpreting this as using long arithmetic for integer overflow and taking low 32-bits of result. In this sense suggested optimization is legal.

But we may have bugs in VM. I suggest to add a regression test to compare golden (from Interpreter) values with results from optimized compiled code for all interesting/corner cases.

@vnkozlov Thanks for confirmation.

I added a test as you suggested, but not sure it covers all interesting/corner cases, please advise.

Copy link
Contributor

@vnkozlov vnkozlov left a comment

Repetitive copy-past code pattern concern me - prone to bugs. Can you consider using next pattern instead:

   if (op1 == Op_MulI && op2 == Op_MulI) {
     Node* add_in1 = NULL;
     Node* add_in2 = NULL;
     Node* mul_in = NULL;
     if (in1->in(1) == in2->in(1)) {
       // Convert "a*b+a*c into a *(b+c)
       add_in1 = in1->in(2);
       add_in2 = in2->in(2);
       mul_in = in1->in(1);
...
     if (mul_in != NULL) {
       Node* add = phase->transform(new AddINode(add_in1, add_in2));
       return new MulINode(mul_in, add);
     }

Copy link
Contributor

@vnkozlov vnkozlov left a comment

I am fine with your selection of corner cases in the test.
You need second test file for long values.

// Method should be compiled
private static int addComp(int a, int b, int c) {
return a * b + a * c;
}
Copy link
Contributor

@vnkozlov vnkozlov Jul 14, 2021

Choose a reason for hiding this comment

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

You don't need separate method for compilation. First call will be executed in interpreter.

private static int addInt(int a, int b, int c) {
return a * b + a * c;
Copy link
Contributor

@vnkozlov vnkozlov Jul 14, 2021

Choose a reason for hiding this comment

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

You need tests for all order variations you optimized.

Copy link
Contributor

@vnkozlov vnkozlov left a comment

Good.

You need second review.

@openjdk
Copy link

@openjdk openjdk bot commented Jul 14, 2021

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

8270366: C2: Add associative rule to add/sub node

Reviewed-by: kvn, adinn

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

  • c962e6e: 8261006: 'super' qualified method references cannot occur in a static context
  • 99d7f9a: 8264908: Investigate adding BOT range check in G1BlockOffsetTablePart::block_at_or_preceding
  • e92e2fd: 8270517: Add Zero support for LoongArch
  • 7a89ffe: 8270014: Add scoped objects for g1 young gc verification and young gc internal timing
  • 793d772: 8270475: Remove unused G1STWDrainQueueClosure
  • 1ebd946: 8270333: -XX:+VerifyStringTableAtExit should not do linear search
  • 04b73bc: 8269656: The test test/langtools/tools/javac/versions/Versions.java has duplicate test cycles
  • 7c23491: 8269598: Regressions up to 5% on aarch64 seems due to JDK-8268858
  • 7d0edb5: Merge
  • 7b4d84c: 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848
  • ... and 29 more: https://git.openjdk.java.net/jdk/compare/375fc2a2b29c454b36d3ae068a080b28f6ec04e9...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.

@openjdk openjdk bot added the ready label Jul 14, 2021
adinn
adinn approved these changes Jul 15, 2021
Copy link
Contributor

@adinn adinn left a comment

This is definitely clearer and the test is a good safety net.

@zhengyu123
Copy link
Contributor Author

@zhengyu123 zhengyu123 commented Jul 15, 2021

@adinn @vnkozlov Thanks for the review

@zhengyu123
Copy link
Contributor Author

@zhengyu123 zhengyu123 commented Jul 15, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Jul 15, 2021

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

  • 1f995e5: 8265888: StandardJavaFileManager::setLocationForModule specification misses 'Implementation Requirements:'
  • c962e6e: 8261006: 'super' qualified method references cannot occur in a static context
  • 99d7f9a: 8264908: Investigate adding BOT range check in G1BlockOffsetTablePart::block_at_or_preceding
  • e92e2fd: 8270517: Add Zero support for LoongArch
  • 7a89ffe: 8270014: Add scoped objects for g1 young gc verification and young gc internal timing
  • 793d772: 8270475: Remove unused G1STWDrainQueueClosure
  • 1ebd946: 8270333: -XX:+VerifyStringTableAtExit should not do linear search
  • 04b73bc: 8269656: The test test/langtools/tools/javac/versions/Versions.java has duplicate test cycles
  • 7c23491: 8269598: Regressions up to 5% on aarch64 seems due to JDK-8268858
  • 7d0edb5: Merge
  • ... and 30 more: https://git.openjdk.java.net/jdk/compare/375fc2a2b29c454b36d3ae068a080b28f6ec04e9...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Jul 15, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Jul 15, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jul 15, 2021

@zhengyu123 Pushed as commit 746fe5d.

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

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