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

Emanuel Peter epeter at openjdk.org
Thu Dec 15 13:30:30 UTC 2022


> **Working on new fix... Will update this later**
> 
> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - removing old fix, will push new fix later
 - Merge branch 'master' into JDK-8298176
 - remove swap files, how did I ever commit them?
 - tab to whitespace
 - code style improvements
 - 8298176: remove OpaqueZeroTripGuardPostLoop once main-loop disappears

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/22/files
  - new: https://git.openjdk.org/jdk20/pull/22/files/b83c995e..d70b385d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=22&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=22&range=01-02

  Stats: 282 lines in 20 files changed: 52 ins; 164 del; 66 mod
  Patch: https://git.openjdk.org/jdk20/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/22/head:pull/22

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


More information about the hotspot-compiler-dev mailing list