RFR: JDK-8309266: C2: assert(final_con == (jlong)final_int) failed: final value should be integer

[Roland Westrelin]

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.

Let's say CCP is running. Init and limit are not `ConINode`s at this point but once CCP is over, it will have discovered that they are actually constants so will make them `ConINode`s. The change you're making will have prevented CCP from propagating the constants through `LoopLimitNode` making CCP more pessimistic that it needs to be.

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

PR Comment: https://git.openjdk.org/jdk/pull/14490#issuecomment-1593242034