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