RFR: 8315066: Add unsigned bounds and known bits to TypeInt/Long [v18]
Dean Long
dlong at openjdk.org
Wed Sep 18 19:03:14 UTC 2024
On Thu, 12 Sep 2024 16:49:22 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:
>> src/hotspot/share/opto/type.hpp line 661:
>>
>>> 659: // the below constraints, see contains(jint)
>>> 660: const jint _lo, _hi; // Lower bound, upper bound in the signed domain
>>> 661: const juint _ulo, _uhi; // Lower bound, upper bound in the unsigned domain
>>
>> Can't we do without explicit fields to record unsigned hi / lo ?
>> We just need to present a unsigned view of signed _lo and _hi which can be done using safe macros.
>
> No we can't, consider `TypeInt::NON_ZERO`. It would have `_lo = min_jint`, `_hi = max_jint`, `_zeros = 0`, `_ones = 0`. Which make it impossible to distinguish from `TypeInt::INT` without unsigned bounds.
Ignoring the unsigned issue for a moment, and going back to Dual, if we had the concept of Complement, we could represent NON_ZERO as the complement of 0 <= x <= 0, which would be x > 0 || x < 0. In general, the complement of lo <= x <= hi would be x > hi || x < lo, in contrast to the dual, which I believe is defined as the non-intuitive hi <= x <= lo. I think complement would allow us to represent more complicated expressions, such as !(x>=lo && x<=hi).
If both dual and complement can be used to map between join and meet, then of the two complement seems more attractive and intuitive. But maybe there is another reason we need dual than I'm missing.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17508#discussion_r1765559677
More information about the hotspot-compiler-dev
mailing list