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

[Vladimir Kozlov]

On Thu, 5 Sep 2024 15:34:54 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/opto/rangeinference.hpp line 46:
>> 
>>> 44:  * Bits that are known to be 0 or 1. A value v satisfies this constraint iff
>>> 45:  * (v & zeros) == 0 && (~v & ones) == 0. I.e, all bits that is set in zeros
>>> 46:  * must be unset in v, and all bits that is set in ones must be set in v.
>> 
>> That is quite counter-intuitive. Is there a good reason for this?
>> I would have expected that `zero[i] = 1` would mean that a zero is allowed, and `ones[i] = 1` that a one is allowed.
>> 
>> Basically, when I see `zero[i]` I expect it to be a boolean that answers me this question: "can it be a zero?". But you are telling me I'm supposed to ask "Must it not be a zero"?
>> 
>> You are telling me that `zero[i] = 1` and `ones[i] = 0` means that it must be a `1`.
>> 
>> I know that changing it now would be a lot of effort. But the risk of being unintuitive is that even less people can quickly fix bugs in this code.
>> 
>> @vnkozlov what do you think about this?
>
> You are a bit confused, the `zeros` and `ones` answer the question: Must this bit be 0 (or 1). Which means that `zero[i] = 1` means that the bit must be a `0`.

The condition could be converted to `(v & ones) == ones && (v & zeros) == 0`. 
It is matching your statement and easy to understand. I would let C++ compiler to optimize it instead of encoding it in confusing way.

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

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