[jdk17] RFR: 8268883: C2: assert(false) failed: unscheduable graph

Christian Hagedorn chagedorn at openjdk.java.net
Fri Jul 2 10:13:00 UTC 2021


On Fri, 2 Jul 2021 09:12:13 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The IR graph has a diamond shaped:
> (If (Bool (CmpI ...)))/Region/Phi.
> 
> One of the Phi's input is a chain of arithmetic operations. The last
> of the chain is a CastII in one branch of the If. The input of the
> CastII is also the input of a CmpI node that's input to the If. The
> other input of the CmpI becomes a constant. That causes the CastII's
> type be narrower because of logic in CastIINode::Value(). The improved
> type percolates through the chain of arithmetic operations. The type
> of a ConvL2I in the chain is updated to a narrower type as a
> consequence. Now the other input of the CmpI becomes a constant and as
> a consequence the branch of the diamond where the arithmetic
> operations are is never taken. What would next happen, is the ConvL2I
> becomes top (because its narrow type and its input type do not
> overlap), one of the Phi inputs would become top and the Phi would be
> replaced by the remaining input. The If would constant fold and only
> one branch would be kept. But before that has a chance to happen,
> PhiNode::Ideal() runs and is_cond_add() transforms it into a:
> 
> (AddI (AndI ..))
> 
> with one input that's the ConvL2I. When that input becomes top, the
> AndI becomes top and the AddI that replaced the Phi too. So indirectly
> the Phi is replaced by top which shouldn't have happened.
> 
> The fix I propose is to delay the is_cond_add() (and similar
> transformations) until the CmpI has a chance to be transformed. I
> think it's enough to fix this issue because:
> 
> - As long as one of the If projections has a use other than the
>   Region/Phi (such as the CastII), is_cond_add() is not applied
> 
> - the CastII is the root of the problem because it's what narrows the
>   type so much that some node becomes top. The CastII can only be
>   removed once its input becomes constant and in that case the CmpI's
>   input is also a constant and the CmpI is enqueued for IGVN

That looks reasonable.

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/201


More information about the hotspot-compiler-dev mailing list