Integrated: 8273115: CountedLoopEndNode::stride_con crash in debug build with -XX:+TraceLoopOpts

[Roland Westrelin]

On Mon, 11 Apr 2022 12:30:32 GMT, Roland Westrelin <roland at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: dc635844
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dc6358444b34a4861758a6b41aeebbe737345106
Stats:     64 lines in 2 files changed: 64 ins; 0 del; 0 mod

8273115: CountedLoopEndNode::stride_con crash in debug build with -XX:+TraceLoopOpts

Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/8178