Integrated: 8290711: assert(false) failed: infinite loop in PhaseIterGVN::optimize
Roland Westrelin
roland at openjdk.org
Fri Aug 26 08:00:15 UTC 2022
On Mon, 22 Aug 2022 09:52:47 GMT, Roland Westrelin <roland at openjdk.org> wrote:
> In the test case: the loop is an infinite loop but loop optimizations
> don't add a NeverBranch node because the loop is reachable from Root
> (following Root's inputs) through a null check in the loop body. When
> CCP runs, it finds the null check never fails. PhaseCCP::transform()
> works through the graph starting from Root and following its inputs.
> But because the null check never fails, it doesn't follow the path to
> the loop body and it doesn't update the type of nodes in the loop body
> (as done in PhaseCCP::transform_once()). That's wrong as the loop body
> is not dead. As a consequence, for one CastPP node, its bottom type
> and the type recorded in PhaseCCP's type table differ. When igvn runs
> next, for some nodes, MemNode::Ideal_common() sees a difference
> between the address type recorded by igvn and the one reported by
> bottom_type(). That causes memory nodes to be indefinitely
> re-enqueued for igvn.
>
> The fix I propose is similar to one Tobias implemented in the valhalla
> repo (JDK-8265973). With this fix, all loops are always considered
> reachable by PhaseCCP::transform() (which I think, worst case, is only
> a waste of compilation time but has no correctness issue). To achieve
> that safepoints are collected by CCP before PhaseCCP::transform()
> transform() follows inputs from Root and safepoints.
This pull request has now been integrated.
Changeset: 6354a57b
Author: Roland Westrelin <roland at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/6354a57b5cb85d31ea70a998202470467402b669
Stats: 112 lines in 3 files changed: 112 ins; 0 del; 0 mod
8290711: assert(false) failed: infinite loop in PhaseIterGVN::optimize
Reviewed-by: chagedorn, kvn
-------------
PR: https://git.openjdk.org/jdk/pull/9961
More information about the hotspot-compiler-dev
mailing list