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)?
> 
> We never peel before predicates. Peeling does not know about them. The peeled iteration is placed between predicates and peeled loop head.

The comment in PhaseIdealLoop::do_peeling() implies that the peeled iteration is above the predicates. We can apply loop  predication then peeling. If the peeled iteration is above the predicates, isn’t there a risk the peeled iteration is executed before a predicate it depends on for correctness?

Roland.

> 
> Vladimir
> 
>> 
>> Roland.