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

Emanuel Peter epeter at openjdk.org
Mon Nov 4 13:00:43 UTC 2024


On Sun, 20 Oct 2024 16:41:19 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 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/rangeinference.cpp line 30:

> 28: #include "utilities/tuple.hpp"
> 29: 
> 30: constexpr juint SMALLINT = 3; // a value too insignificant to consider widening

If you are already refactoring this code, I'd suggest giving it a better name. Seems to have to do with cardinality...?

src/hotspot/share/opto/type.cpp line 4690:

> 4688:     const Type* tm = _ary->meet_speculative(tap->_ary);
> 4689:     const TypeAry* tary = tm->isa_ary();
> 4690:     if (tary == nullptr) {

Can you add a comment why this might happen?

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

src/hotspot/share/opto/type.hpp line 632:

> 630:  * a. t._lo >= 0. Since 0 <= t._lo <= jint(t._ulo), we have:
> 631:  *
> 632:  * juint(t._lo) <= juint(jint(t._ulo)) == t._ulo <= juint(t._lo)

You should say what steps you are applying here... otherwise the reader has a lot to do.
Lemma, return-cast, `t._lo <= jint(t._ulo)` (maybe its own Lemma2?)

src/hotspot/share/opto/type.hpp line 634:

> 632:  * juint(t._lo) <= juint(jint(t._ulo)) == t._ulo <= juint(t._lo)
> 633:  *
> 634:  * Which means that t._lo == jint(t._ulo). Similarly, t._hi == jint(t._uhi).

Hmm. I feel like I don't immediately see the "Similarly" here.... too many hidden steps.

test/hotspot/gtest/opto/test_rangeinference.cpp line 33:

> 31: #include <limits>
> 32: 
> 33: #ifdef ASSERT

Why do you have this here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1827691915
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1827665859
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1827673619
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1827676703
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1827680285
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1827684121


More information about the hotspot-compiler-dev mailing list