[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?

This is an example of what happens with `test_001`:
Long loop -> loop-nest
inner loop of loop nest is PeelMainPost-ed
main loop is empty_loop -> removed
CCP after loop-opts:
detect that backedge of outer loop-nest is never taken.
Hence, initial value to PeelMainPost suddently changes to constant.
constant propagates through peeled iteration,
constant determines that zero-trip guard of main loop always goes to main loop
constant folds through empty_loop (previously main loop), exit value is now also constant.
constant arrives at zero-trip guard for post-loop, and also as the initial value for post loop.
Post-loop internals detect that that constant is outside trip-count phi range -> all becomes TOP.
But Opaque of zero trip guard protects the decay of the zero-trip guard.
End of CCP after loop-opts
Eventually, we have the if of the post-zero-trip guard with only one projection out (post loop projection has decayed).

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

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