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

[Quan Anh Mai]

On Thu, 1 May 2025 07:01:26 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> 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?
>
> Yes, because the bit at alignment is 0, this operation just sets it to 1 and set all bits after to 0. So there is no overflow here.

Added a sentence to clarify that this computation cannot overflow.

>> 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?
>
> It is the latter. From the overview, we can see that this function returns an invalid answer if and only if there exists no valid answer (no value not less than `lo` and satisfies `bits`). This clarifies further that in such cases, the algorithm will always return `bits._ones`.

Added a section to describe specifically which computation overflows in this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r2069927921
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r2069928220