RFR: 8281322: C2: always construct strip mined loop initially (even if strip mining is disabled) [v4]

[Roland Westrelin]

> Some of the long range check transformations take advantage of the
> safepoint captured by loop strip mining to extract jvm state (in order
> to add back empty predicates to the inner loop of a loop nest). As a
> consequence, irTests/TestLongRangeChecks.java fails with strip mining
> off and users might experience performance anomalies where changing
> GCs affect purely computational code.
> 
> The strip mined loop nest creation is a 2 step process:
> 
> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>   but it's not fully constructed
> 
> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>   actual loop by adding Phis and a proper exit condition
> 
> I propose always doing 1- whether loop strip mining is enabled or
> not. This causes the safepoint to always be captured. Loop strip ming
> is not expected to get in the way of loop transformations so this
> change in itself should be performance neutral. Then at 2-, if loop
> strip mining is not enabled, the OuterStripMinedLoop can be removed
> and the safepoint moved back into the loop in case
> LoopStripMiningIter=1 or simply removed too.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  build fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7364/files
  - new: https://git.openjdk.java.net/jdk/pull/7364/files/e277b7d1..62d8d875

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7364&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7364&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7364/head:pull/7364

PR: https://git.openjdk.java.net/jdk/pull/7364