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

[Emanuel Peter]

On Fri, 2 May 2025 00:50:31 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 one additional commit since the last revision:
> 
>   Emanuel's reviews

Comments for `intn_t.hpp`

src/hotspot/share/utilities/intn_t.hpp line 36:

> 34: 
> 35: template <unsigned int n>
> 36: class intn_t {

Can we have some description of this class?
What is it for / what does it do?

src/hotspot/share/utilities/intn_t.hpp line 37:

> 35: template <unsigned int n>
> 36: class intn_t {
> 37:   static_assert(n > 0 && n <= 8, "should not be larger than char");

Does `n` stand for the number of bits? Maybe you could write `bits` or even `NUM_BITS` instead?

src/hotspot/share/utilities/intn_t.hpp line 55:

> 53:   explicit constexpr operator int() const {
> 54:     int shift = 32 - n;
> 55:     return int(_v << shift) >> shift;

Suggestion:

    // Sign extension.
    int shift = 32 - n;
    return int(_v << shift) >> shift;

Correct?

src/hotspot/share/utilities/intn_t.hpp line 58:

> 56:   }
> 57: 
> 58:   constexpr static int min = std::numeric_limits<unsigned int>::max() << (n - 1);

Ok, so the lower `n-1` bits are zero, and the uppermost is `1`. Why not just shift up a `1`? Or do you actually care about the upper bits? What exactly is the general assumption about the upper bits?

src/hotspot/share/utilities/intn_t.hpp line 134:

> 132: };
> 133: 
> 134: }

Could use indentation to make clear where the namespace starts and ends. Or at least a comment like this:
Suggestion:

namespace std {

template <unsigned int n>
class numeric_limits<intn_t<n>> {
public:
  constexpr static intn_t<n> min() { return intn_t<n>(intn_t<n>::min); }
  constexpr static intn_t<n> max() { return intn_t<n>(intn_t<n>::max); }
};

template <unsigned int n>
class numeric_limits<uintn_t<n>> {
public:
  constexpr static uintn_t<n> min() { return uintn_t<n>(uintn_t<n>::min); }
  constexpr static uintn_t<n> max() { return uintn_t<n>(uintn_t<n>::max); }
};

} // namespace std

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

PR Review: https://git.openjdk.org/jdk/pull/17508#pullrequestreview-2811428757
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r2071263630
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r2071266208
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r2071269567
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r2071286524
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r2071324433