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

[Roland Westrelin]

On Mon, 7 Mar 2022 16:53:45 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> 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 with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - more
>  - Merge branch 'master' into JDK-8281322
>  - more
>  - cleanup
>  - merge fix
>  - Merge branch 'master' into JDK-8281322
>  - more
>  - more
>  - more
>  - Merge branch 'master' into JDK-8281322
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/5c187e34...a3876c4a

I pushed a number of new commits that address 3 issues (with LoopStripMiningIter=1):
1- the previous logic would drop nodes pinned on the backedge when the loop nest is transformed back to a single loop.
2- sunk stores need to be moved back into the loop which requires the inner loop's memory graph to be updated. I reused existing logic for that (OuterStripMinedLoopNode::fix_sunk_stores())
3- long counted loop support has a similar transform from a loop nest back to a single counted loop. That transform didn't have part 2 above. I'm not sure if it can cause actually bugs as I expect the counted loop to be transformed back to a loop nest next. In any case, rather than duplicate the logic, I refactored the code so it calls the new OuterStripMinedLoopNode::transform_to_counted_loop() instead. Having it callable from both igvn and loop opts requires some care.

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

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