RFR: 8370200: Crash: assert(outer->outcnt() >= phis + 2 - be_loads && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis

[Daniel Lundén]

On Tue, 9 Dec 2025 09:08:53 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The question is how do you reliably get 94 on the igvn queue.
In this particular case, PhiNode::Ideal() creates 451 and enqueues it on the igvn queue with register_new_node_with_optimizer(). Do we want to add custom logic in PhiNode::Ideal() to also enqueue all memory Phis that are uses of the region?
It's likely not sufficient in the general case as, maybe, the transformation can only happen once one input of the bottom Phi is changed. So do we need something like PhaseIterGVN::add_users_of_use_to_worklist() as well? It wouldn't quite the same as we wouldn't enqueue uses of a use but the uses of a common input (the region)?

I'm not sure about the exact mechanism, but it would be nice if `PhiNode::Ideal` adds all relevant nodes to the worklist after creating a new Bot memory Phi. Optimally, we'd like `VerifyIterativeGVN` to notify us of any missing cases. Sounds like two follow-up issues: (1) support `Phi` nodes in `VerifyIterativeGVN` and (2) use the information from `VerifyIterativeGVN` to fix missing cases.

> Or rather than having logic in a couple different places to enqueue the non bottom memory Phi, maybe, we can do that in PhiNode::Ideal for the bottom Phi which would essentially bethe patch I propose but, instead of making any change to the graph, it would enqueue the non bottom Phi so PhiNode::Identity does the change. It seems a bit wasteful to delay the change to the graph when it can be done safely in PhiNode::Ideal for the bottom memory Phi which is why I went with the change I propose.

Right, this is what I propose to fix the present issue and it seems cleaner to me (we let `Identity` handle the identity transformations). I doubt there'll be a measurable compilation time difference. I don't have a strong opinion though, so we can go with what you propose as well. Let's see what other reviewers think before we make a decision!

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

PR Comment: https://git.openjdk.org/jdk/pull/28677#issuecomment-3631485810