RFR: 8371065: C2 SuperWord: VTransformLoopPhiNode::apply setting type leads to assert/wrong result [v10]

Quan Anh Mai qamai at openjdk.org
Tue Nov 11 13:09:33 UTC 2025


On Tue, 11 Nov 2025 09:50:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> In `VTransformLoopPhiNode::apply`, we may have to modify the type of the phi node, because it may have been turned from a scalar phi to a vector phi by `VTransformReductionVectorNode::optimize_move_non_strict_order_reductions_out_of_loop`. This logic was refactored in https://github.com/openjdk/jdk/pull/27704, and I missed some edge cases that the fuzzer now found.
>> 
>> - The first issue: when we (uslessly) set the type of phis that stay scalar: the `in1` type can be a constant, and then we set the `phi` type to be constant. And then the phi wrongly constant folds. That leads to wrong results.
>> - The second issue: a phi that was scalar and we turned into vector still had some dead old scalar reduction nodes attached. They would of course eventually die during IGVN. But with `StressIGVN` just picking the right bad order, it could happen that an `AddI` attached to the `phi` would try to figure out its `Value` type, and try to combine the vector type of the `phi` with the other input, leading to a type error.
>> 
>> With only the first issue at first, I tried to improve the way we modify the type from scalar to vector. But with the second issue, it became clear that we should just create a new phi node when we move from scalar to vector phi. Hence, I split the `LoopPhi` into a `PhiScalar` and a `PhiVector`,  and give them separate implementations.
>> 
>> ---------
>> 
>> Thanks @rwestrel for filing this issue and spending a lot of time reproducing it without his changes.
>> I tried to find a simpler reproducer, but it was difficult: We need a constant on the lhs of the phi in the main-loop. But this requires us to constant-fold the pre-loop phi, and somehow magically not constant fold the phi of the main-loop. That is quite tricky, and I gave up.
>> 
>> Later, the fuzzer found the second reproducer on mainline, which was much easier to reduce.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add -XX:+UnlockDiagnosticVMOptions flag

Thanks a lot for your fix

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

Marked as reviewed by qamai (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28113#pullrequestreview-3447988295


More information about the hotspot-compiler-dev mailing list