RFR: 8314116: C2: assert(false) failed: malformed control flow after JDK-8305636

[Vladimir Kozlov]

On Fri, 11 Aug 2023 08:13:57 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> In the test case, a Template Assertion Predicate is not removed when a loop is dying. After applying more loop opts, it ends up above a different loop. We then peel this loop and create an Initialized Assertion Predicate from the template which gets completely unrelated values from the already removed loop. This causes some nodes to die and we end up with a broken graph.
> 
> This problem of not removing Template Assertion Predicates of dying loops which end up at different loops was already known before JDK-8305636 (see [analysis in JDK-8305428](https://bugs.openjdk.org/browse/JDK-8305428?focusedCommentId=14571901&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14571901)). 
> 
> Apparently, with JDK-8305636, this became much more likely because I've accidentally already included a fix for Loop Peeling when moving some refactorings from the complete fix ([JDK-8288981](https://bugs.openjdk.org/browse/JDK-8288981)) to JDK-8305636. The included fix creates Initialized Assertion Predicates when peeling a loop even though Parse Predicates have already been removed. This needs to be done eventually but seems to trigger JDK-8305428 more often with a different manifestation.
> 
> I therefore suggest to revert Loop Peeling back to the old state:
> https://github.com/openjdk/jdk/blob/a38fdaf18dfeeb23775516d1986c720190ba9fc2/src/hotspot/share/opto/loopTransform.cpp#L781-L789
> 
> https://github.com/openjdk/jdk/blob/a38fdaf18dfeeb23775516d1986c720190ba9fc2/src/hotspot/share/opto/loopTransform.cpp#L2068-L2075
> 
> where we only create Initialized Assertion Predicates if there are actually Parse Predicates available.
> 
> Thanks,
> Christian

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15244#pullrequestreview-1574004777