RFR: 8273115: CountedLoopEndNode::stride_con crash in debug build with -XX:+TraceLoopOpts
Roland Westrelin
roland at openjdk.java.net
Mon Apr 11 12:37:17 UTC 2022
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
https://github.com/openjdk/jdk/pull/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.
-------------
Commit messages:
- fix
Changes: https://git.openjdk.java.net/jdk/pull/8178/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8178&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8273115
Stats: 64 lines in 2 files changed: 64 ins; 0 del; 0 mod
Patch: https://git.openjdk.java.net/jdk/pull/8178.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/8178/head:pull/8178
PR: https://git.openjdk.java.net/jdk/pull/8178
More information about the hotspot-compiler-dev
mailing list