RFR: 8374180: C2 crash in PhaseCCP::verify_type - fatal error: Not monotonic

[Quan Anh Mai]

Hi,

The issue here is the inconsistency in computing the `_widen` field of the `TypeInt`. At the first step, the types of the operands are:

    t1 = int:0
    t2 = int:-2..3, widen = 3

Since the type of the first operand is a constant zero, `AddNode::Value` returns the type of the second operand directly, as `x ^ 0 == x for all x`. In the second step, `t1` is widened to `0..2`. This triggers the real computation of the result. The algorithm then splits `t2` into `t21 = int:-2..-1` and `t22 = int:0..3`. The `Xor` of these with `t1` are `r1 = int:-4..-1` and `r2 = int:0..3`. As both have `_hi - _lo <= SMALL_TYPEINT_THRESHOLD == 3`, their `_widen`s are normalized to `0`. As a result, their `meet` also has `_widen == 0`. This value is smaller than that from the previous step, which was `3`, which leads to the failure.

The root cause here is that, the `_widen` value of a node should be computed and normalized on the whole range of the node, not on its subranges, which may normalize it to `0` in more cases than what is expected. As a result, my proposed solution is to ignore the `_widen` value of the subranges, and pass the expected `_widen` value when composing the final result.

Please take a look and leave your reviews, thanks a lot.

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

Commit messages:
 - RangeInference::infer should ensure correct value of _widen

Changes: https://git.openjdk.org/jdk/pull/28952/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28952&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374180
  Stats: 79 lines in 4 files changed: 65 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28952/head:pull/28952

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