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

[Roland Westrelin]

http://cr.openjdk.java.net/~roland/8139771/webrev.00/

In PhiNode::Ideal(), when all uncasted inputs are identical, the Phi is removed which can cause a control dependency to be lost. See the test case (which includes a step by step description of how this can lead to a bad graph) for an example. The test case crashes on sparc with -XX:+StressGCM.

To fix that I propose that rather than simply replacing the Phi by its uncasted input, we replace it by a CastPP that is specially marked as carrying a dependency (similar to what we have for CastII). That fixes this issue and should protect us from other similar issues:

- I moved the _carry_dependency from CastII to ConstraintCast and CheckCastPP so it applies to CastPP, CastII and CheckCastPP
- I added code to remove the casts that carry a dependency if there’s a dominating cast with identical inputs and a more restrictive type. I made is_dominator() a virtual method of PhaseTransform so we can have an implementation in GVN and use the same code during GVN and loop opts
- We can now have a chain of CastPP with a control so the code in final_graph_reshaping shouldn’t go follow through a CastPP only if its control is null
- I changed the code in PhaseCFG::schedule_pinned_nodes() to handle controls that are in the same block

I performed extensive perf testing on x86 and sparc and found not statistically significant regressions.

Roland.