RFR: 8370332: C2 SuperWord: SIGSEGV because PhaseIdealLoop::split_thru_phi left dead nodes in loop _body
    Roland Westrelin 
    roland at openjdk.org
       
    Mon Oct 27 13:46:47 UTC 2025
    
    
  
On Thu, 23 Oct 2025 14:23:38 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
> Analysis:
> `split_thru_phi` can split a node out of the loop, through some loop phi. As a consequence, that node and the phi we split through can become dead. But `split_thru_phi` did not have any logic to yank the dead node and phi from the `_body`. If this happens in the same loop-opts-phase as a later SuperWord, and that SuperWord pass somehow accesses that loop `_body`, then we may find dead nodes, which is not expected.
> 
> It is not ok that `split_thru_phi` leaves dead nodes in the `_body`, so they have to be yanked.
> 
> What I did additionally: I went through all uses of `split_thru_phi`, and moved the `replace_node` from the call-site to the method itself. Removing the node and yanking from `_body` conceptually belongs together, so they should be together in code.
> 
> I suspect that `split_thru_phi` was broken for a long time already. But JDK26 changes in SuperWord started to check inputs of all nodes in `_body`, and that fails with dead nodes.
> 
> Future Work:
> - Continue work on making `VerifyLoopOptimizations` work again, we should assert that there are no dead nodes in the `_body`. We may do that with the following task, or a subsequent one.
>   - [JDK-8370332](https://bugs.openjdk.org/browse/JDK-8370332) Fix VerifyLoopOptimizations - step 3 - fix ctrl/loop
src/hotspot/share/opto/loopopts.cpp line 241:
> 239:       Node* in = n->in(j);
> 240:       // Check that in is a phi, and n was its only use.
> 241:       if (in->is_Phi() && in->in(0) == region &&
Does that work if, say, we're splitting:
`(Add (Phi ..) (Phi ..)`
With a single `Phi` as input twice? Doesn't the `Phi` have 2 uses then (the `Add`, twice)?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27955#discussion_r2465736832
    
    
More information about the hotspot-compiler-dev
mailing list