[jdk20] RFR: 8298176: remove OpaqueZeroTripGuardPostLoop once main-loop disappears

[Roland Westrelin]

On Tue, 13 Dec 2022 07:08:59 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> We recently removed `Opaque2` nodes in [JDK-8294540](https://bugs.openjdk.org/browse/JDK-8294540). `Opaque2` nodes prevented some optimizations during loop-opts. The original idea was to prevent the use of both the un-incremented and incremented value of a loop phi after the loop, to reduce register pressure. But `Opaque2` also had the effect that the limit of the loop would not be optimized, which meant that the iv-value (entry value of phi) in post loop would never collapse (either to constant or TOP), but always remain a range. Now that `Opaque2` is gone, it can happen that when the main-loop disappears, the limit collapses. The zero-trip guard of the post-loop would be false, but does not collapse because of the `OpaqueZeroTripGuard`. The post-loop can half-collapse, leaving an inconsistent graph below the zero-trip guard if.
> 
> **Solution**
> Have `OpaqueZeroTripGuardMainLoop` for main loop zero-trip guard, and `OpaqueZeroTripGuardPostLoop` for post-loop zero trip guard. Let `OpaqueZeroTripGuardPostLoop` remove itself once it cannot find the main-loop above it. We have these opaque nodes there to prevent collapsing of the zero-trip guards as long as the limits may still change, but after the main-loop is removed, no unrolling is done anymore, so the limit of the post-loop cannot change anymore, hence it is safe to remove the opaque node there.
> 
> An alternative approach was to let the main-loop remove the opaque node of the post-loop's zero-trip guard. But that does not work reliably, as the main-loop may get removed during PhaseCCP, and the main-loop is simply removed as "useless". Hence the LoopNode of the main-loop does not have a chance to detect its death during IGVN.

OpaqueZeroTripGuardPostLoopNode::Identity() only runs if it's enqueued in the igvn workqueue, that is in the general case if its input changes. I'm not sure it's guaranteed that when the main loop looses its backedge for instance, the OpaqueZeroTripGuardPostLoopNode ends up being processed. The 2 feels like separate events. So I wonder if that fix is robust enough.

How does the main loop disappear during CCP? Is it still there but it's backedge is removed? Or is the entire loop removed? If that's the case, is that because of predicates?

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

PR: https://git.openjdk.org/jdk20/pull/22