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