-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
8275847: Scheduling fails with "too many D-U pinch points" on small method #6131
Conversation
…ethod Since around JDK 16 the following method cannot be compiled by C2 on AArch64: public double mergeSync() { return Math.log(Math.sin(value)); } (Reduced from a slightly larger benchmark.) 811 416 ! 3 Test::mergeSync (61 bytes) 813 417 ! 4 Test::mergeSync (61 bytes) 816 417 ! 4 Test::mergeSync (61 bytes) COMPILE SKIPPED: too many D-U pinch points (retry at different tier) 816 418 ! 1 Test::mergeSync (61 bytes) Scheduling::anti_do_def() will create temporary Nodes for each OptoReg killed by the MachProjs from the two runtime leaf calls. After SVE support was added these runtime calls kill more registers, and the number of new Nodes added by anti_do_def exceeds an internal limit (which is based on the LRG map size and roughly proportional to the method size). X86 has the same problem if OptoScheduling is enabled because of the wide AVX registers. The fix here is to ignore OptoRegs which correspond to the high slots of wide vectors (i.e. slots above 64 bits). The scheduler doesn't run on methods where C->max_vector_size() > 8, so we know these kills can't affect the scheduling result. The added test fails on the current JDK with: compiler.lib.ir_framework.shared.TestRunException: Could not compile public double compiler.c2.irTests.TestScheduleSmallMethod.testSmallMethodTwoRuntimeCalls(double) at level C2 after 10s. Last compilation level: 3
👋 Welcome back ngasson! A progress list of the required criteria for merging this PR into |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While looking at the usages of is_concrete
, I found that all current usages outside of asserts are dead:
jdk/src/hotspot/share/opto/buildOopMap.cpp
Line 234 in 1750a6e
if (false && r->is_reg() && !r->is_concrete()) { |
jdk/src/hotspot/share/opto/buildOopMap.cpp
Line 315 in 1750a6e
if (b->is_stack() || b->is_concrete() || true ) { |
jdk/src/hotspot/share/opto/buildOopMap.cpp
Line 320 in 1750a6e
if (b->is_stack() || b->is_concrete() || true ) { |
jdk/src/hotspot/share/opto/buildOopMap.cpp
Line 350 in 1750a6e
if ( callee->is_concrete() || true ) { |
I think we should clean that up.
Looks like it's been like that since the initial public commit in 2007. I folded the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me but a second review would be good.
/reviewers 2
@nick-arm 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:
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 139 new commits pushed to the
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to me but I need to run testing before approval.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing results look good.
Thanks for the reviews. The Windows x64 build failure looks to be spurious, I re-ran the GitHub actions here: https://github.com/nick-arm/jdk/runs/4133872978 |
/integrate |
Going to push as commit 3934fe5.
Your commit was automatically rebased without conflicts. |
Since around JDK 16 the following method cannot be compiled by C2 on AArch64:
(Reduced from a slightly larger benchmark.)
Scheduling::anti_do_def() will create temporary Nodes for each OptoReg killed by the MachProjs from the two runtime leaf calls. After SVE support was added these runtime calls kill more registers, and the number of new Nodes added by anti_do_def exceeds an internal limit (which is based on the LRG map size and roughly proportional to the method size).
X86 has the same problem if OptoScheduling is enabled because of the wide AVX registers.
The fix here is to ignore OptoRegs which correspond to the high slots of wide vectors (i.e. slots above 64 bits). The scheduler doesn't run on methods where C->max_vector_size() > 8, so we know these kills can't affect the scheduling result.
The added test fails on the current JDK with:
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6131/head:pull/6131
$ git checkout pull/6131
Update a local copy of the PR:
$ git checkout pull/6131
$ git pull https://git.openjdk.java.net/jdk pull/6131/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 6131
View PR using the GUI difftool:
$ git pr show -t 6131
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6131.diff