RFR: 8361699: C2: assert(can_reduce_phi(n->as_Phi())) failed: Sanity: previous reducible Phi is no longer reducible before SUT
Roberto Castañeda Lozano
rcastanedalo at openjdk.org
Mon Sep 8 15:43:10 UTC 2025
On Thu, 4 Sep 2025 07:44:52 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:
> Hi Cesar, thanks for addressing this issue. I will run some more comprehensive testing and have a look at it in the next days.
Testing did not reveal any issue. I have, however, a high-level question: could the current two-step design ([SR state adjustment loop](https://github.com/openjdk/jdk/blob/166ef5e7b1c6d6a9f0f1f29fedb7f65b94f53119/src/hotspot/share/opto/escape.cpp#L300-L315) followed by a [NSR propagation loop](https://github.com/openjdk/jdk/blob/166ef5e7b1c6d6a9f0f1f29fedb7f65b94f53119/src/hotspot/share/opto/escape.cpp#L318-L320) miss marking allocations as NSR in more complex scenarios, e.g. involving longer points-to/merge chains? Wouldn't it be more principled to re-run the SR state adjustment loop until a fixed point is reached, keeping `reducible_merges` consistent as new allocations are discovered to be NSR? (e.g. by calling `revisit_reducible_phi_status` - with your clean-up applied - every time [an allocation is marked as NSR due to non-removable merges](https://github.com/openjdk/jdk/blob/166ef5e7b1c6d6a9f0f1f29fedb7f65b94f53119/src/hotspot/share/opto/escape.cpp#L2962-L2964)).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27063#issuecomment-3266887455
More information about the hotspot-compiler-dev
mailing list