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

[Emanuel Peter]

On Tue, 13 Dec 2022 19:23:08 GMT, Vladimir Kozlov <kvn 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.
>
> "The zero-trip guard of the post-loop would be false, but does not collapse because of the OpaqueZeroTripGuard. "
> Can we just look only for this condition (guard is false) instead of looking through graph to see if main loop disappeared?

@vnkozlov The problem is that the zero-trip guard can be false for a while, because the post loop has no work. But then unrolling changes how much work the main loop does, and can give the post-loop work to do after all. That is the reason we have this opaque node in the first place. Without that opaque node, the condition could be false, we would remove the post loop. But then unrolling wants to give the post-loop some work, but it has already been optimized away.

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

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