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
8273115: CountedLoopEndNode::stride_con crash in debug build with -XX:+TraceLoopOpts #8178
Conversation
|
@rwestrel This change now passes all automated pre-integration checks. 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 80 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.
|
@vnkozlov @TobiHartmann thanks for the reviews |
/integrate |
Going to push as commit dc63584.
Your commit was automatically rebased without conflicts. |
The crash occurs because a counted loop has an unexpected shape: the
exit test doesn't depend on a trip count phi. It's similar to a crash
I encountered in (not yet integrated) PR
#7823 and fixed with an extra
CastII:
https://github.com/openjdk/jdk/pull/7823/files#diff-6a59f91cb710d682247df87c75faf602f0ff9f87e2855ead1b80719704fbedff
That fix is not sufficient here, though. But the fix I proposed here
works for both.
After the counted loop is created initially, the bounds of the loop
are captured in the iv Phi. Pre/main/post loops are created and the
main loop is unrolled once. CCP next runs and in the process, the type
of the iv Phi of the main loop becomes a constant. The reason is that
as types propagate, the type captured by the iv Phi and the improved
type that's computed by CCP for the Phi are joined and the end result
is a constant. Next the iv Phi constant folds but the exit test
doesn't. This results in a badly shaped counted loop. This happens
because on first unroll, an Opaque2 node is added that hides the type
of the loop limit. I propose adding a CastII to make sure the type of
the new limit (which cannot exceed the initial limit) is not lost.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/8178/head:pull/8178
$ git checkout pull/8178
Update a local copy of the PR:
$ git checkout pull/8178
$ git pull https://git.openjdk.java.net/jdk pull/8178/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 8178
View PR using the GUI difftool:
$ git pr show -t 8178
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/8178.diff