RFR: 8361608: C2: assert(opaq->outcnt() == 1 && opaq->in(1) == limit) failed [v9]

[Christian Hagedorn]

On Tue, 28 Oct 2025 07:24:55 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/loopopts/TooStrictAssertForUnrollAfterPeeling.java line 54:
>> 
>>> 52:  *                   -XX:-SplitIfBlocks
>>> 53:  *                   -XX:-UseOnStackReplacement
>>> 54:  *                   -XX:LoopMaxUnroll=2
>> 
>> Are these flags all required to trigger the issue or what is the motivation behind having this run compared to the above only?
>
> That's the one in the reproducer you've crafted that give a simpler graph, if I remember correctly. I think it's valuable because the graph shape is different so it might trigger some asserts differently, exercise other paths, and if it breaks again, maybe someone who will have to look at it will be happy to find a run with a simpler graph. Maybe I can add in the summary that "if it helps investigate an issue, the @run 3 and 5 (with more flags) are expected to give a simpler graph".

Thanks for the explanation. But it would also trigger without the additional flags? For the reproducer, I just disabled as many optimizations as possible to get an easier graph which I often do while debugging. The problem I see is that we could define such additional runs in many of our tests to get some simpler or different graph shapes. But I would argue that this should rather be part of a separate stress job instead. This also keeps the execution time short for tier1. But you could certainly leave a comment in the test how to get a simpler graph if required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27586#discussion_r2468993153