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
vlivanov at openjdk.java.net
Thu Jun 10 14:52:58 UTC 2021
On Thu, 10 Jun 2021 12:03:24 GMT, Roland Westrelin <roland at openjdk.org> wrote:
>> src/hotspot/share/opto/loopopts.cpp line 1510:
>>
>>> 1508: // is only added once both AddP nodes are sunk (see special code for AddP after the cast is created).
>>> 1509: if (x->in(0) == NULL && !x->is_DecodeNarrowPtr() &&
>>> 1510: !(x->is_AddP() && x->in(AddPNode::Address)->is_AddP() && x->in(AddPNode::Address)->in(AddPNode::Base) == x->in(AddPNode::Base))) {
>>
>> I read the last check as "not a case of chained AddP with different bases".
>> Then the comparison should be `!=`, shouldn't it?
>
> It's safe to add a cast if it's not a chained AddP with the same base otherwise there's a risk that adding a cast would make the base differ.
Got it. Wasn't attentive enough when reading the description and the comment.
>> src/hotspot/share/opto/loopopts.cpp line 1523:
>>
>>> 1521: register_new_node(cast, x_ctrl);
>>> 1522: x->replace_edge(in, cast);
>>> 1523: if (x->is_AddP() && k == AddPNode::Base) {
>>
>> Does the code assume that "inner" node is processed first?
>> Otherwise, the "outer" node could be already processed and bases don't match anymore.
>>
>> I'm asking because `PhaseIdealLoop::split_if_with_blocks()` (which calls `split_if_with_blocks_post()` and `try_sink_out_of_loop()` does process users first.
>
> The expectation is that uses are processed first. The:
> !(x->is_AddP() && x->in(AddPNode::Address)->is_AddP() && x->in(AddPNode::Address)->in(AddPNode::Base) == x->in(AddPNode::Base))
> check guarantees the "outer" node doesn't change the base when it's processed. When the "inner" node is processed, bases for the inner and outer node are updated.
A comment briefly explaining what's happening here may help as well.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4387
More information about the hotspot-compiler-dev
mailing list