RFR: JDK-8309266: C2: assert(final_con == (jlong)final_int) failed: final value should be integer
Eric Nothum
duke at openjdk.org
Thu Jun 15 16:14:58 UTC 2023
On Thu, 15 Jun 2023 10:43:53 GMT, Eric Nothum <duke at openjdk.org> wrote:
> **Acknowledgments**: Thanks to @quadhier for the preliminary work on this issue: https://github.com/openjdk/jdk/pull/14353
>
> **JDK-8309266**: TestLoopLimitOverflowDuringCCP.java causes an assertion error (overflow check) in LoopLimitNode::Value. To fix the issue I added a check in LoopLimitNode::Value that verifies that the input nodes are ConI type nodes.
>
> Previously, TestLoopLimitOverflowDuringCCP would cause the assertion error in LoopLimitNode::Value, during PhaseCCP::analyze. The problem originated from PhaseCCP initializing all types to TOP, resulting in the Phi node from `int limit = flag ? 1000 : Integer.MAX_VALUE` being temporarily considered as Integer.MAX_VALUE. This happens as the Node for the Integer.MAX_VALUE case was already analyzed by CCP while the Node for the 1000 case was still initialized to TOP. When resolving the value of the Phi node, Integer.MAX_VALUE and TOP get merged to Integer.MAX_VALUE, which is then processed by LoopLimitNode::Value as a constant, resulting in the integer overflow.
>
> By checking that the input nodes are ConI nodes in LoopLimitNode::Value, we avoid Phi nodes being misinterpreted during PhaseCCP. If the Phi nodes turn out to be constant they should rather be first transformed to ConI nodes.
yes that's an issue, I did not realize that the change could slow the CCP down this way. I guess, defaulting to bottom in case of an overflow might be the better option then.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14490#issuecomment-1593357726
More information about the hotspot-compiler-dev
mailing list