RFR: 8353290: C2: Refactor PhaseIdealLoop::is_counted_loop() [v23]

Kangcheng Xu kxu at openjdk.org
Thu Nov 27 19:04:16 UTC 2025


On Tue, 25 Nov 2025 14:08:26 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix trip counter loop-variant detection
>
> src/hotspot/share/opto/loopnode.cpp line 1832:
> 
>> 1830:   while (xphi->Opcode() == Op_Cast(_iv_bt)) {
>> 1831:     xphi = xphi->in(1);
>> 1832:   }
> 
> I'm wondering if this should be part of the `xphi` computation in `LoopIVStride`. Or in other words: Do the other use-sites of `xphi()` do not need this uncast logic? Maybe @rwestrel knows more.

Iterative uncasting was introduced in #25539, and I think that pr missed updating what's now `PhaseIdealLoop::check_counted_loop_shape()`, the only other caller of `xphi()`. `check_counted_loop_shape()` asserts after a loop nest is created. However,  [new test cases in #25539](https://github.com/openjdk/jdk/blob/8a0672c819e09a16c30fbdf58dc2b81f50958da4/test/hotspot/jtreg/compiler/loopopts/TestCountedLoopCastIV.java) does not create loop nests (if I understand correctly), and they didn't trigger this assertion which would otherwise fail.

It's safe to add this to `xphi()`. I'm not sure if created loop nests would contain this multiple-cast pattern at all, but it shouldn't break anything even they don't.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24458#discussion_r2569790528


More information about the hotspot-compiler-dev mailing list