RFR [9] (XS): 8179882: C2: Stale control info after cast node elimination during loop optimization pass

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Wed May 24 22:50:26 UTC 2017


Thanks for the review, Vladimir.

> Yes, calling IGVN during loop opts is dangerous - we always have to
> remember adjust loops info.
>
> On 5/24/17 9:18 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8179882/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8179882
>>
>> There's cast elimination logic in
>> PhaseIdealLoop::split_if_with_blocks_pre() which was introduced by
>> JDK-8139771.
>>
>> The problem with it is that ConstraintCastNode::dominating_cast()
>> relies on immediate control info (in(0)) which can get out of sync
>> with what is cached in PhaseIdealLoop (get_ctrl()).
>
> Should we fix this instead? It means somewhere we forgot to update loop
> info.

Can you elaborate your point, please? The fix being proposed does 
exactly that - detect the case when dom_cast should be moved and updates 
its control & loop info to dominate all users (dom_lca(dom_cast_ctrl, 
n_ctrl)).

Or do you suggest to rewrite ConstraintCastNode::dominating_cast() to 
use get_ctrl() instead of in(0)?

Best regards,
Vladimir Ivanov

>>
>> The fix is to catch the case when dom_cast doesn't dominate n based on
>> info from PhaseIdealLoop and update control info accordingly.
>>
>> Testing: manual (replayed problematic compilation & eyeballed the IR),
>> JPRT, RBT (hs-tier0-comp, in progress).
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> PS: thanks to Roland for helping with the fix.


More information about the hotspot-compiler-dev mailing list