RFR: 8271203: C2: assert(iff->Opcode() == Op_If || iff->Opcode() == Op_CountedLoopEnd || iff->Opcode() == Op_RangeCheck) failed: Check this code when new subtype is added

[Yi Yang]

On Thu, 29 Jul 2021 09:12:34 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> I don't think that a `LongCountedLoop` is unswitched here looking at the stack trace but it's rather chosen as unswitch `If`. I had a closer look at it. It seems that the loop
> 
> ```
> for (long l1 = i; l1 < 2; ++l1) {
>      iArrFld[0] += 5;
> }
> ```
> 
> is peeled once and then the original loop is found to be dead (because it is known that the type of the iv `i` of the outer-most loop is >= 1). From this peeled iteration we only have `403 LongCountedLoopEnd` left which now just acts as a normal `If` node. It looks fine to then simply use this as an unswitch if for unswitching `367 CountedLoop`. So, relaxing the assert to allow a `LongCountedLoopEnd` node in `dominated_by` looks good IMO.

Hi Christian, I think you are right. As far as I see, after some loop optimizations, loop at line-17 and loop at line-19 are no longer real loops after PhaseIdealLoop2:

![image](https://user-images.githubusercontent.com/5010047/129343365-a1cdede8-74bf-4227-8a24-c0dd88a0a7f5.png)

I'm not sure why there are two same loops(B9 and B19-B22) .. but anyway, 403#LongCountedLoopEnd is located in B21, it's not a loop anymore since no backedge found and C2 treats it as a unswitch_iff.

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

PR: https://git.openjdk.java.net/jdk/pull/4920