RFR: 8253644: C2: assert(skeleton_predicate_has_opaque(iff)) failed: unexpected

Christian Hagedorn chagedorn at openjdk.java.net
Fri Nov 27 08:50:56 UTC 2020


On Thu, 26 Nov 2020 12:35:48 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> > Some additional optimizations are then applied such that the fast loop no longer has any backedge/path to the parent loop while the slow loop still has.
> 
> Does one round of loop opts stop here...
> and another starts below?
> 
> > As a result, the loop tree building algorithm only recognizes the slow loop as child while the fast loop is not. The fast loop is treated as a separate loop on the same level as the parent loop:
> 
> > ```
> > [N459, but the loop could actually be removed in the meantime but the skeleton predicates are still there]
> > ```
> 
> I don't understand that part. Is N459 no longer a loop?

Yes, exactly. So, we unswitch in one round A. Then we have the first loop tree shown with the slow and fast loop at the start of the next round B. In this round B, we apply Split If that is then able to remove the [`IfNode` (2)](https://github.com/chhagedorn/jdk/blob/cfc7c941ddefd716c9f07bf7e8f4824f00bb7e9b/test/hotspot/jtreg/compiler/loopopts/TestUnswitchCloneSkeletonPredicates.java#L101). We always take the true projection ( `x == 100` is true) which means that we immediately exit the fast loop N459 on the first iteration. The `CountedLoopNode` is therefore removed. The second loop tree shown is at the start of the next round C where we then finally apply the peeling and pre/main/post steps which lets the assertion fail. This description of N459 is indeed a bit misleading. When afterwards talking about the fast loop I just mean where the fast loop was before to keep things simpler.

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

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


More information about the hotspot-compiler-dev mailing list