RFR: 8269820: C2 PhaseIdealLoop::do_unroll get wrong opaque node

[Roland Westrelin]

A main loop loses its pre loop. The Opaque1 node for the zero trip
guard of the main loop is assigned control at a Region through which
an If is split. As a result, the Opaque1 is cloned and the zero trip
guard takes a Phi that merges Opaque1 nodes. One of the branch dies
next and as, a result, the zero trip guard has an Opaque1 as input but
at the wrong CmpI input. The assert fires next.

The fix I propose is that if an Opaque1 node that is part of a zero
trip guard is encountered during split if, rather than split if up or
down, instead, assign it the control of the zero trip guard's
control. This way the pattern of the zero trip guard is unaffected and
split if can proceed. I believe it's safe to assign it a later
control:

- an Opaque1 can't be shared

- the zero trip guard can't be the If that's being split

As Vladimir noted, this bug used to not reproduce with loop strip
mining disabled but now always reproduces because the loop
strip mining nest is always constructed. The reason is that the
main loop in this test is kept alive by the LSM safepoint. If the
LSM loop nest is not constructed, the loop is optimized out. I
filed:

https://bugs.openjdk.org/browse/JDK-8297724

for this issue.

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

Commit messages:
 - more
 - test
 - more
 - fix

Changes: https://git.openjdk.org/jdk/pull/11391/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11391&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8269820
  Stats: 169 lines in 6 files changed: 167 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11391.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11391/head:pull/11391

PR: https://git.openjdk.org/jdk/pull/11391