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

[Vladimir Kozlov]

On 5/24/17 3:50 PM, Vladimir Ivanov wrote:
> 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)).

Could be misunderstanding. You said get_ctrl() does not point to in(0) 
at time when dominating_cast() is called. My question is why? During 
loop construction it should point to it. At which time it is changed?

If there was a new node created during loopopts then 
PhaseIdealLoop::register_new_node() should be called for it already.

Vladimir K

> 
> 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.