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

[Quan Anh Mai]

On Mon, 4 Nov 2024 08:57:23 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
>> 
>>  - Merge branch 'master' into unsignedbounds
>>  - address reviews
>>  - comment adjust_lo empty case
>>  - formality
>>  - address reviews
>>  - add comments, refactor functions to helper class
>>  - refine comments
>>  - remove leftover code
>>  - add doc to TypeInt, rename parameters, remove unused methods
>>  - change (~v & ones) == 0 to (v & ones) == ones
>>  - ... and 22 more: https://git.openjdk.org/jdk/compare/309b9291...7f3316fa
>
> src/hotspot/share/opto/type.hpp line 620:
> 
>> 618:  *
>> 619:  * 2. Either _lo == jint(_ulo) and _hi == jint(_uhi), or all elements of a
>> 620:  * TypeInt lie in the intervals [_lo, jint(_uhi)] or [jint(_ulo), _hi]
> 
> The `[_lo, jint(_uhi)] or [jint(_ulo), _hi]` in english is not precise enough.
> - Is it a mathematical `OR`: the element can also be in both? In that case I would add "or both".
> - Is it a mathematical `XOR`? Then I would write "either ... or .. but not both"

In this case the intervals are disjoint so it is equivalent whether it is a `OR` or a `XOR`.

> src/hotspot/share/opto/type.hpp line 630:
> 
>> 628:  * For a TypeInt t, there are 3 possible cases:
>> 629:  *
>> 630:  * a. t._lo >= 0. Since 0 <= t._lo <= jint(t._ulo), we have:
> 
> I think you should say why `t._lo <= jint(t._ulo)` ... it seems intuitively true... hmm

It is because `t._lo` is the smallest element of `t` in the signed domain so `t._ulo` must be not less than `t._lo` in the signed domain.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1840307875
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1840309915