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

[Roland Westrelin]

As described in https://github.com/openjdk/jdk20/pull/22, the bug is
caused by the iv phi of a post loop that becomes top but because the
post loop is guarded by an opaque node, the control flow remains
alive.

The fix I propose is based on this comment Vladimir made:
https://github.com/openjdk/jdk20/pull/22#issuecomment-1349570615

When CmpINode::Value() encounters a (CmpI (OpaqueZeroTripGuard in1)
in2), it runs Value() on (CmpI in1 in2) and if it constant folds so
that the loop is not taken, returns that result. Translating "loop not
taken" into an actual CmpI type depends on whether the loop goes up or
down. To make the check above possible, OpaqueZeroTripGuard includes
the BoolTest::mask that causes the loop to be executed at the zero
trip guard.

The new logic in CmpINode::Value() is executed for both the main and
post loop zero trip guards (while the bug was only seen AFAIK with the
post loop) because I expect the same bug to exist with the main loop.

For the main loop, this works because initially the loop should be
executed and as optimizations proceed and adjust the zero trip guard,
the range of iterations executed in the loop should narrow (and never
widen). We may then end up with no iterations executed in the loop. No
further optimizations would make the main loop executable again. It's
then fine to fold the zero trip guard as we're done with
optimizations.

This works for the post loop because the compiler has no way to tell
whether it's executed or not as long as there's a main loop: the zero
trip guard then takes as input a phi that merges the pre and main loop
ivs. For the case of a loop going up, the zero trip guard should
initially test whether [init, limit] (the type of phi) is stricly less
than limit. The compiler can't decide what the result of that test
is. As optimizations proceed, the [init, limit] range could become
narrower as I understand and there's no risk for the compiler to
report the post loop as not taken.

I still believe it's risky to simply drop the OpaqueZeroTripGuard for
the post loop even if it can't constant fold at least because we
wouldn't want the zero trip guard to split thru phi.

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

Commit messages:
 - fix & test

Changes: https://git.openjdk.org/jdk20/pull/65/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=65&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298176
  Stats: 191 lines in 7 files changed: 188 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/65.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/65/head:pull/65

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