RFR: 8280600: C2: assert(!had_error) failed: bad dominance

[Vladimir Kozlov]

On Tue, 1 Feb 2022 15:03:33 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> For the inner loop of the test, c2, first, creates a counted loop and
> assigns the type -400..1 to the trip count Phi. The loop body has a
> range check that guards a CastII on the trip count Phi. That CastII
> has type: 0..1 as a result.
> 
> Pre/main/post loops are then created. In the process,
> PhaseIdealLoop::cast_incr_before_loop() inserts a CastII right before
> the main loop. That CastII's input is the add node of the pre
> loop. The loop is also unrolled once. The CastII on the loop entry is
> pushed through the add node and replaced by the range check CastII
> that has the same input and dominates. As a result, the main loop
> tripcount Phi has type -400..1 but init value, 1..2. This causes the
> Phi to constant fold to 1. The amount of unrolling and the main loop
> bounds are inconsistent (the loop shouldn't be unrolled if it executes
> for one iteration) but when the unrolling decision is made the type of
> the lower bound of the main loop is not yet accurately known.
> 
> The actual crash is the result of a chain of nodes sunk out of the
> inner loop and pinned out of the loop with a CastII node. The type of
> the CastII and the type of its input after unrolling conflict.
> 
> The fix I propose is to change the type of the CastII that's added
> before the main loop so it can't be replaced by a dominating
> CastII. Given that CastII's role is to carry dependencies for nodes in
> the loop body on the loop entry test, I think it's the right thing to
> do. I've also been working on 8275202 (C2: optimize out more redundant
> conditions) as a way to avoid type inconsistencies like this one.

Seems good. Will run testing before approval.

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

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