RFR: 8315066: Add unsigned bounds and known bits to TypeInt/Long [v53]

[Emanuel Peter]

On Thu, 1 May 2025 06:57:29 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch adds unsigned bounds and known bits constraints to TypeInt and TypeLong. This opens more transformation opportunities in an elegant manner as well as helps avoid some ad-hoc rules in Hotspot.
>> 
>> In general, a `TypeInt/Long` represents a set of values `x` that satisfies: `x s>= lo && x s<= hi && x u>= ulo && x u<= uhi && (x & zeros) == 0 && (x & ones) == ones`. These constraints are not independent, e.g. an int that lies in [0, 3] in signed domain must also lie in [0, 3] in unsigned domain and have all bits but the last 2 being unset. As a result, we must canonicalize the constraints (tighten the constraints so that they are optimal) before constructing a `TypeInt/Long` instance.
>> 
>> This is extracted from #15440 , node value transformations are left for later PRs. I have also added unit tests to verify the soundness of constraint normalization.
>> 
>> Please kindly review, thanks a lot.
>> 
>> Testing
>> 
>> - [x] GHA
>> - [x] Linux x64, tier 1-4
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - wording
>  - grammar, more details for non-existence

src/hotspot/share/opto/rangeinference.cpp line 306:

> 304:     // a value not less than lo and satisfies bits. This is because there is
> 305:     // always a bit up to first_violation that is 0 in both lo and zeros
> 306:     // (trivially, it is the bit at first_violation).

Essencially, you are saying that the addition in the alignment for `new_lo` cannot overflow, right?

src/hotspot/share/opto/rangeinference.cpp line 362:

> 360:     // if there is no bit up to first_violation that is 0 in both lo and zeros,
> 361:     // i.e. tmp == 0. In such cases, alignment == 0 && lo == bits._ones. It is
> 362:     // the only case when this function does not return a valid answer.

Wow, that sounds like your algorithm is broken. Or is it still valid, it just overflows, and gets you a result smaller than `lo`, but that is actually expected?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r2069914112
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r2069915747