RFR: 8308504: C2: "malformed control flow" after JDK-8303466

[Emanuel Peter]

On Thu, 22 Jun 2023 13:54:37 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>>> > It doesn't seem to be true that the loop incr never overflows in the general case. See this example:
>>> 
>>> But don't we check that the limit is small enough at runtime, such that there cannot be an overflow? We do that with `check_stride_overflow` and `insert_loop_limit_check_predicate`. And if it does overflow, we do not go into the counted-loop, but we uncommon trap, I think. Or are you sure that we actually enter the counted-loop with your example? Or just some peeled version?
>> 
>> Ran with:
>> 
>>  -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -XX:-TieredCompilation -XX:CompileOnly=TestOverflowCountedLoopIncr::test -XX:CompileCommand=quiet -XX:LoopMaxUnroll=0 -XX:+UseCountedLoopSafepoints 
>> 
>> I see a single counted loop, no uncommon trap in the IR.
>
>> @rwestrel so you think the `incr` can indeed overflow, and that is ok? Or would that be a bug? Why do we even have the loop limit check in the first place, if overflow is allowed?
> 
> To guarantee no overflow requires init < limit (for a loop going up). Nothing guarantees that when c2 pattern matches a counted loop. Whether overflow is a problem or not would require taking a closer look at individual optimizations.

@rwestrel ok. Well if overflow for the `incr` in indeed in general allowed, then my approach is fundamentally flawed.

But maybe we can fix this specific case with your idea, of inserting a `CastII` for the limit, after we do the loop limit check, so that the check actually has an effect on the type of the limit.

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

PR Comment: https://git.openjdk.org/jdk/pull/14331#issuecomment-1602746932