RFR: 8267988: C2: assert(!addp->is_AddP() || addp->in(AddPNode::Base)->is_top() || addp->in(AddPNode::Base) == n->in(AddPNode::Base)) failed: Base pointers must match (addp 1301) [v3]

[Vladimir Ivanov]

On Thu, 10 Jun 2021 09:27:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The failure occurs because, in a loop body, two AddP nodes are
>> chained:
>> (AddPNode base (AddPNode base ..) ..)
>> 
>> One can be sunk out of loop but not the other which results in:
>> (AddPNode (CastPP base) (AddPNode base ..) ..)
>> 
>> And the 2 AddP nodes no longer have the same base.
>> 
>> The fix I propose is to make sure sinking nodes out of loop preserve
>> the invariant that 2 chained AddP nodes have the same base. It's not
>> straightfoward given the 2 AddP nodes are sunk one after the other and
>> when sinking the first one, it's hard to tell whether the second one
>> can be sunk as well.
>> 
>> With the fix:
>> 
>> - when the first AddP is sunk, no CastPP node is added to pin the AddP
>>   out of the loop so if sinking the second AddP fails, the 2 AddP
>>   nodes still have the same base.
>> 
>> - when the second AddP is sunk, a CastPP node is created and wired so
>>   both AddP base is updated to the new CastPP.
>> 
>> This change also addresses another unrelated minor issue. If, for
>> instance the loop has a null check, the loop body already includes a
>> CastPP. So if that CastPP is used by an AddP that is sunk, we end up
>> with:
>> 
>> (AddPNode (CastPP (CastPP...
>> 
>> Then code in ConstraintCastNode::dominating_cast(), causes the CastPP
>> added to pin the AddP out of loop to be replaced by the CastPP in the
>> loop so sinking the AddP has no effect. To prevent that, I tweaked the
>> way a ConstrainedCast is marked as carrying a dependency so
>> ConstraintCastNode::dominating_cast() doesn't trigger.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - review
>  - merge
>  - review
>  - review
>  - fix

Thanks for the clarifications, Roland.

Looks good.

A more general question: does it make sense to migrate away from pointer equality (`in(AddPNode::Base) == in(AddPNode::Address)->in(AddPNode::Base)`) to `Node::eqv_uncast()` (`in(AddPNode::Base)->eqv_uncast(in(AddPNode::Address)->in(AddPNode::Base))`) when checking the shape of address computation? If it is doable, it would avoid the whole class of related bugs.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4387