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