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