RFR: 8360175: C2 crash: assert(edge_from_to(prior_use, n)) failed: before block local scheduling

[Christian Hagedorn]

On Tue, 8 Jul 2025 13:00:45 GMT, Manuel Hässig <mhaessig at openjdk.org> wrote:

>> src/hotspot/cpu/x86/peephole_x86_64.cpp line 349:
>> 
>>> 347:     Node* dependant_lea = decode->fast_out(i);
>>> 348:     if (dependant_lea->is_Mach() && dependant_lea->as_Mach()->ideal_Opcode() == Op_AddP) {
>>> 349:       dependant_lea->set_req(AddPNode::Base, lea_derived_oop->in(AddPNode::Address));
>> 
>> The fix looks reasonable to me, too. No worries about the regression test, thanks for trying! A small question: Why don't we use `lea_address`?
>> 
>> Another thing I've noticed while browsing the code: `ra_` and `new_root` seem to be unused and could be removed (could probably also be squeezed into this PR here instead of creating a new issue just for that).
>
> We cannot use `lea_address` because in case of a spill that also gets moved up one node to check if the lea and the decode point to the same grandparent.
> 
>> Another thing I've noticed while browsing the code: ra_ and new_root seem to be unused and could be removed.
> 
> These arguments come from the machinery that calls this out of the matcher. I am not too familiar with it, so my working assumption so far has been to keep the signature the same as the other peepholes, which seems logical since it is called by generated code.

Thanks for the explanation, makes sense.

> These arguments come from the machinery that calls this out of the matcher. I am not too familiar with it, so my working assumption so far has been to keep the signature the same as the other peepholes, which seems logical since it is called by generated code.

Could be the case - I'm not too familiar with it, either. Anyway, the fix looks good!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26157#discussion_r2193326173