RFR: 8366888: C2: incorrect assertion predicate with short running long counted loop

Roland Westrelin roland at openjdk.org
Fri Sep 12 09:12:26 UTC 2025


On Fri, 12 Sep 2025 08:57:57 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> In:
> 
> 
>         for (int i = 100; i < 1100; i++) {
>             v += floatArray[i - 100];
>             Objects.checkIndex(i, longRange);
>         }
> 
> 
> The int counted loop has both an int range check and a long range. The
> int range check is optimized first. Assertion predicates are inserted
> above the loop. One predicates checks that:
> 
> 
> init - 100 <u floatArray.length
> 
> 
> The loop is then transformed to enable the optimization of the long
> range check. The loop is short running, so there's no need to create a
> loop nest. The counted loop is mostly left as is but, the loop's
> bounds are changed from:
> 
> 
>         for (int i = 100; i < 1100; i++) {
> 
> 
> to:
> 
> 
>         for (int i = 0; i < 1000; i++) {
> 
> 
> The reason for that the long range check transformation expects the
> loop to start at 0.
> 
> Pre/main/post loops are created. Template Assertion predicates are
> added above the main loop. The loop is unrolled. Initialized assertion
> predicates are created. The one created from the condition:
> 
> 
> init - 100 <u floatArray.length
> 
> 
> checks the value of `i` out of the pre loop which is 1. That check fails.
> 
> The root cause of the failure is that when bounds of the counted loop
> are changed, template assertion predicates need to be updated with and
> adjusted init input.
> 
> When the bounds of the loop are known, the assertion predicates can be
> updated in place. Otherwise, when the loop is speculated to be short
> running, the assertion predicates are updated when they are cloned.

Thanks @chhagedorn for the test case

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

PR Comment: https://git.openjdk.org/jdk/pull/27250#issuecomment-3284433245


More information about the hotspot-compiler-dev mailing list