RFR(M): 8216135: C2 assert(!had_error) failed: bad dominance

Vladimir Kozlov vladimir.kozlov at oracle.com
Sun Jan 13 21:34:20 UTC 2019


Looks reasonable.

Did you test with switched off UseLoopPredicate?

Thanks,
Vladimir

On 1/9/19 1:59 AM, Roland Westrelin wrote:
> 
> http://cr.openjdk.java.net/~roland/8216135/webrev.00/
> 
> Range check elimination is applied to a loop and then the loop is
> unrolled. After the loop is unrolled, the range of values for the
> induction variable conflicts with a range check CastII (the loop is over
> unrolled and the main loop would never be executed), the CastII's value
> becomes top, a data path dies but the corresponding control path is kept
> alive. This results in a broken graph.
> 
> This scenario is supposed to be caught by the skeleton predicates added
> by 8193130 but it's not for 2 reasons:
> 
> 1- With 8203915 & 8205033, Tobias extended skeleton predicates to cover
>    not only the first value of the induction variable of the first loop
>    iteration but also the last value of an unrolled loop. But his changes
>    only apply to loop predicates, not range check elimination.
> 
> 2- With 8203915 & 8205033, Tobias used an Opaque1 node as a place holder
>    so on each unrolling, he could update the skeleton predicate with the
>    new stride. The problem is that the Opaque1 node blocks type
>    propagation and the skeleton predicate only has a chance to remove a
>    dead main loop after loop opts are over. In the case of this bug, the
>    CastII becomes dead before loop opts are finished.
> 
> The problem with 2- is that if the Opaque1 node is not added, on the
> next unrolling there's no way to find what predicate and what part of
> the predicate to update. The fix I propose, is to keep 3 predicates
> after the first unrolling:
> 
> 1 for the first value of the first iteration
> 1 for the last value of the last iteration, without an Opaque1 node
> 1 with an Opaque1 node that can be used as a template
> 
> On the next unrolling pass, the 1st and 2nd predicates above could have
> been optimized out. Rather than try to locate and update the 2nd
> predicate, the 1st and 2nd predicates are removed if they are found and,
> once the code finds the 3rd predicate, it clones it once to produce the
> check on the first value again and a second time to produce an updated
> check on the new last value.
> 
> Roland.
> 


More information about the hotspot-compiler-dev mailing list