RFR  (XS): 8179882: C2: Stale control info after cast node elimination during loop optimization pass
vladimir.kozlov at oracle.com
Wed May 24 22:55:45 UTC 2017
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:
>>> There's cast elimination logic in
>>> PhaseIdealLoop::split_if_with_blocks_pre() which was introduced by
>>> 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
> 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,
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.
> 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