RFR: 8342692: C2: long counted loop/long range checks: don't create loop-nest for short running loops [v24]

[Roland Westrelin]

On Wed, 21 May 2025 09:10:44 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
>> 
>>  - Merge branch 'master' into JDK-8342692
>>  - more
>>  - compilation fix
>>  - new benchmark
>>  - Add benchmark for manual mismatch loop
>>  - review
>>  - Merge branch 'master' into JDK-8342692
>>  - Update src/hotspot/share/opto/loopnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/opto/graphKit.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/50a7755f...6100f757
>
> src/hotspot/share/opto/loopnode.cpp line 1156:
> 
>> 1154: 
>> 1155:   void visit(const ParsePredicate& parse_predicate) override {
>> 1156:     _clone_predicate_to_loop.clone_parse_predicate(parse_predicate, true);
> 
> `clone_parse_predicate()` has its second parameter named `is_false_path_loop`. I think that no longer makes sense because we are now reusing the method outside Loop Unswitching.. Maybe we should just rename the parameter to `rewire_uncommon_proj_phi_inputs` which is eventually the name in `create_new_if_for_predicate()`. Additionally, we should rename `ParsePredicate::clone_to_unswitched_loop()` to `clone_to_loop()`. What do you think?

Sounds good. New commit has this renaming. Question now is what we do with `ParsePredicate::trace_cloned_parse_predicate()` that wouldn't always print a message that makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21630#discussion_r2100117924