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

[Roland Westrelin]

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.