RFR(S): 8139771: Eliminating CastPP nodes at Phis when they all come from a unique input may cause crash

[Roland Westrelin]

> For reference, current webrev:
> 
> http://cr.openjdk.java.net/~roland/8139771/webrev.01/
> 
>>> As you suggested I made CheckCastPP inherit from ConstraintCast. I also hit the following bug: one iteration of a loop is peeled which causes a CastPP to be pinned between the loop and the predicates. When a predicate that depends on the CastPP is moved out of the loop, it is moved above the CastPP. I fixed by marking all nodes that depend on a node pinned between a loop and the predicates as non loop invariant. I don’t think fixing it by moving the cast up above the predicates is a safe fix in general.
>> 
>> Hmm. The test which depends on CastPP should be also peeled and it will dominate the test in main loop. If a test/predicate could be moved from main loop then it should be possible to use peeled one. What do you think?
> 
> Let me take another look at this.
> Independently: so we never apply loop predication before peeling? Otherwise moving the peeled body before the loop predicate could be incorrect, right (predicates could have been moved out of the body before it’s peeled)?

So it’s not a peel but a partial peel. The CastPP has _carry_dependency set to true. My concern is that if _carry_dependency is true, we lost track of why we have that CastPP so I wonder if there can be a hidden dependency between the CastPP and the predicates: a pass of loop predication moves stuff out of the loop, that allowed some optimizations to proceed that resulted in the CastPP with _carry_dependency and then the loop is partially peeled.

Roland.