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

Emanuel Peter epeter at openjdk.org
Mon Nov 4 10:20:39 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

Sorry, I've been very slow on this. A few more comments before lunch.

src/hotspot/share/opto/rangeinference.hpp line 159:

> 157: 
> 158:   template <class CT>
> 159:   static bool int_type_subset(const CT* super, const CT* sub) {

Suggestion:

  static bool is_int_type_equal(const CT* t1, const CT* t2) {
    return t1->_lo == t2->_lo && t1->_hi == t2->_hi &&
           t1->_ulo == t2->_ulo && t1->_uhi == t2->_uhi &&
           t1->_bits._zeros == t2->_bits._zeros && t1->_bits._ones == t2->_bits._ones;
  }

  template <class CT>
  static bool is_int_type_subset(const CT* super, const CT* sub) {

I think these should be `is_...` names.

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

> 614:  *
> 615:  * 1. Since every TypeInt instance is canonicalized, all the bounds must also
> 616:  * be elements of such TypeInt. Or else, we can tighted the bounds by narrowing

Suggestion:

 * be elements of such TypeInt. Or else, we can tighten the bounds by narrowing

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"

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

> 620:  * TypeInt lie in the intervals [_lo, jint(_uhi)] or [jint(_ulo), _hi]
> 621:  *
> 622:  * Proof: For 2 jint value x, y such that they are both >= 0 or < 0. Then:

Suggestion:

 * Proof: For 2 jint value x, y such that they are both >= 0 or both < 0. Then:

Or are you allowing them to one be positive and one negative?

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

> 643:  * can be seen that _lo and jint(_uhi) are both < 0 or >= 0, and the same
> 644:  * applies to jint(_ulo) and _hi.
> 645:  */

I would appreciate some indentation: it would make it easier to see points 1, 2, ... And to see what is part of the proof, and what is part of a case distinction and each case in it.

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

PR Review: https://git.openjdk.org/jdk/pull/17508#pullrequestreview-2412481589
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1827379995
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1827388140
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1827391449
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1827393271
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1827397025


More information about the hotspot-compiler-dev mailing list