RFR: 8294217: Assertion failure: parsing found no loops but there are some [v2]

Christian Hagedorn chagedorn at openjdk.org
Tue Nov 8 15:33:27 UTC 2022


On Tue, 8 Nov 2022 14:06:38 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This was reported on 11 and is not reproducible with the current
>> jdk. The reason is that the PhaseIdealLoop invocation before EA was
>> changed from LoopOptsNone to LoopOptsMaxUnroll. In the absence of
>> loops, LoopOptsMaxUnroll exits earlier than LoopOptsNone. That wasn't
>> intended and this patch makes sure they behave the same. Once that's
>> changed, the crash reproduces with the current jdk.
>> 
>> The assert fires because PhaseIdealLoop::only_has_infinite_loops()
>> returns false even though the IR only has infinite loops. There's a
>> single loop nest and the inner most loop is an infinite loop. The
>> current logic only looks at loops that are direct children of the root
>> of the loop tree. It's not the first bug where
>> PhaseIdealLoop::only_has_infinite_loops() fails to catch an infinite
>> loop (8257574 was the previous one) and it's proving challenging to
>> have PhaseIdealLoop::only_has_infinite_loops() handle corner cases
>> robustly. I reworked PhaseIdealLoop::only_has_infinite_loops() once
>> more. This time it goes over all children of the root of the loop
>> tree, collects all controls for the loop and its inner loop. It then
>> checks whether any control is a branch out of the loop and if it is
>> whether it's not a NeverBranch.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good, thanks for doing the updates!

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10904


More information about the hotspot-compiler-dev mailing list