RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN [v4]

Pengfei Li pli at openjdk.org
Mon Aug 29 11:34:02 UTC 2022


> Recently, an igvn infinite loop issue was reported. Git bisection shows
> it appears after our JDK-8289996 patch. But after that patch is backed
> out, we find similar test still fails. We have attached a jtreg case to
> reproduce this issue.
> 
> The ideal graph of the problematic method has a `MulINode` multiplying a
> `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()`
> moves the constant input to the right hand side. And `Ideal()` function
> in its parent class `MulNode` has the similar logic. In some code paths,
> `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that,
> `MulINode` and `MulNode` use different ways to check constant. One calls
> `type->singleton()` and the other calls `node->find_int_con(val)` which
> accepts constant in `PhiNode`. So in some corner cases where a `PhiNode`
> can be evaluated to a constant, the two inputs of the `MulNode` will be
> swapped back and forth in `Ideal()` calls. It eventually causes the igvn
> infinite loop issue.
> 
> This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode`
> because it's enough to do this by calling `MulNode::Ideal()`. We also do
> some code cleanup in this patch as we have done in JDK-8289996.
> 
> Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1.

Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Add some minor fixes
 - Merge branch 'master' into igvn
 - Make the code more readable
 - Reword some comments
 - 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN
   
   Recently, an igvn infinite loop issue was reported. Git bisection shows
   it appears after our JDK-8289996 patch. But after that patch is backed
   out, we find similar test still fails. We have attached a jtreg case to
   reproduce this issue.
   
   The ideal graph of the problematic method has a `MulINode` multiplying a
   `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()`
   moves the constant input to the right hand side. And `Ideal()` function
   in its parent class `MulNode` has the similar logic. In some code paths,
   `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that,
   `MulINode` and `MulNode` use different ways to check constant. One calls
   `type->singleton()` and the other calls `node->find_int_con(val)` which
   accepts constant in `PhiNode`. So in some corner cases where a `PhiNode`
   can be evaluated to a constant, the two inputs of the `MulNode` will be
   swapped back and forth in `Ideal()` calls. It eventually causes the igvn
   infinite loop issue.
   
   This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode`
   because it's enough to do this by calling `MulNode::Ideal()`. We also do
   some code cleanup in this patch as we have done in JDK-8289996.
   
   Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1.

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

Changes: https://git.openjdk.org/jdk/pull/9820/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9820&range=03
  Stats: 101 lines in 3 files changed: 81 ins; 4 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/9820.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9820/head:pull/9820

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


More information about the hotspot-compiler-dev mailing list