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

[Emanuel Peter]

On Wed, 14 Dec 2022 06:21:47 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.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove swap files, how did I ever commit them?

We discussed it in the office with Christian and Tobias:
The issue is that the post-loop LoopNode is removed during CCP. The expectation so far was that they only are removed in IGVN, where in RegionNode::Ideal we catch the death of LoopNodes, and remove their `OpaqueZeroTripGuard` nodes above them.
But during CCP, we simply `remove useless` the LoopNode, and its opaque node stays behind. This leads to an inconsistent trip-guard if with only one projection, as the other projection would have lead down to the LoopNode.

We propose this point fix for JDK20:
We should check if's that sit on the boundary and have one projection removed: if they have an `OpaqueZeroTripGuard` (if they are a zero-trip-guard with opaque node), then we hack the condition value, which makes the if die properly during IGVN after CCP. This is in parallel to the removal logic in `RegionNode::Ideal`.

For JDK21 I will also file an RFE to try removing the `OpaqueZeroTripGuardPostLoop` completely (never even insert it).

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

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