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:

>> Hi, I'm trying to fix [JDK-8271203](https://bugs.openjdk.java.net/browse/JDK-8271203). It's reasonable to unswitch LongCountedLoop, so relax it.
>> 
>> ![image](https://user-images.githubusercontent.com/5010047/127302280-0faa90bb-add7-4639-8c63-49668901f267.png)
>
> 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.

Thanks @chhagedorn @rwestrel and @TobiHartmann for reviews.

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

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