RFR: 8328528: C2 should optimize long-typed parallel iv in an int counted loop [v21]

[Kangcheng Xu]

On Wed, 16 Oct 2024 05:13:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> @TobiHartmann. Thanks for the feedback! I did some investigation, reasons for timeouts comes three folds:
>> 
>> 1. Tests with `i <= stop` is not a counted loop in the first place and should be removed:  
>> 
>>     Now I remember why I originally didn't test for it. Consider `for (int i = 0; i <= stop; i++);` when `stop = Integer.MAX_VALUE`. Overflow in Java is well-defined, which means the code must loop indefinitely and optimizations of any kind can't break this. Therefore, `<=` are not counted loops to begin with. `@IR(failOn = {IRNode.COUNTED_LOOP})` doesn't fail either. I removed these test cases.
>> 
>> 2. It is normal to timeout with `-XX:StressLongCountedLoop=200000000` for all test cases:
>> 
>>     An value other than `0` for this flag will forcefully convert int counted loops to long counted loops, which C2 doesn't do parallel IV at this point. This is same issue as [JDK-8294839](https://bugs.openjdk.org/browse/JDK-8294838). Loops are still loops. For a large random `stop` value, this will take a long time to loop through.
>> 
>> 3. It is normal to timeout with `-XX:PerMethodTrapLimit=0` for test cases with stride other than `1`:
>>     
>>     Take `for (int i = 0; i < stop; i += 2)` for an example. Since there is a chance for increment to `i` go beyond `stop` (and eventually overflows), there must be some sort of runtime check for `stop`. Normally, a `loop_limit_check` trap is compiled to take the slow path (deoptimization). However, the zero trap limit forces C2 to loop and check `i < stop` on every iteration. For a large random `stop` value, this will take a long time.
>> 
>> For the latter two reasons, I added `runWithFlags()` to essentially disable the flags in questions. 
>> 
>> https://github.com/openjdk/jdk/blob/845e34cc7a82ef5cb69620a12f487adaca9d2613/test/hotspot/jtreg/compiler/loopopts/parallel_iv/TestParallelIvInIntCountedLoop.java#L47-L51
>
> @tabjy We are still seeing timeouts with `-XX:+UnlockDiagnosticVMOptions -XX:TieredStopAtLevel=3 -XX:+StressLoopInvariantCodeMotion -XX:+StressRangeCheckElimination -XX:+StressLinearScan`. Maybe the test should be enabled only if C2 is available.

@TobiHartmann Yes `-XX:TieredStopAtLevel=3` will cause timeouts. I added the `@requires vm.compiler2.enabled` option to the test header.

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

PR Comment: https://git.openjdk.org/jdk/pull/18489#issuecomment-2417134416