RFR: 8294217: Assertion failure: parsing found no loops but there are some
Tobias Hartmann
thartmann at openjdk.org
Wed Nov 2 08:13:31 UTC 2022
On Fri, 28 Oct 2022 14:34:42 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.
Looks good to me.
-------------
Marked as reviewed by thartmann (Reviewer).
PR: https://git.openjdk.org/jdk/pull/10904
More information about the hotspot-compiler-dev
mailing list