RFR: 8331575: C2: crash when ConvL2I is split thru phi at LongCountedLoop [v2]

[Emanuel Peter]

On Tue, 14 May 2024 07:32:26 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - test case tweaks
>>  - fuzzer test
>
> Before split if:
> 
> long i = 100;
> for (; i > 0;) {
>   // i here is 1..100
>   int j = (int)i; // ConvL2I type is 1..100, same as loop phi
>   int k = 42 / j;
>    i--;
> }
> 
> 
> after split if:
> 
> 
> long i = 100;
> int j = 100;
> int k = 0;
> for (; i > 0;) {
>   // i here is 1..100
>    i--;
>   // i here is 0..99
>   j = (int)i; // ConvL2I type is still 1..100 which is not correct
>   k = 42 / j;
> }

@rwestrel which "split_if" optimization was applied in your example? Split the ConvI2L through the phi? If so, the problem seems to be that the ConvI2L floats by the exit-check, right?


after split if:

long i = 100;
int j = 100;
int k = 0;
for (; i > 0;) {
  // i here is 1..100
   i--;
  // i here is 0..99
  exit check
  // i here is 1..99
  j = (int)i; // ConvL2I type is still 1..100 which is not correct
  k = 42 / j;
}


I guess the issue is that the `ConvL2I` was somehow pinned inside the loop, after the `CountedLoop`, by the `phi`. But when the `ConvL2I` is split into the backedge, it does not stay in the backedge but floats further, passes by the exit-check and goes into the last iteration -> BOOM.

How exactly did we narrow the type to `1...100`? I guess that that is some smart logic in the trip count `Phi` node, right? If instead we had a `CastLL` for the exit check that narrows the type, then the `CastLL` would remain after the split-if, and the split `ConvL2I` could not float from the backedge into the loop body of the last iteration.

So I guess that is really a limitation: a trip count `Phi` specifically does the narrowing, and so you cannot just split past it. The question is if that is really nice, or if we could do it differently, e.g. via a `CastLL/CastII` on the exit-check?

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

PR Comment: https://git.openjdk.org/jdk/pull/19086#issuecomment-2109526424