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

[Quan Anh Mai]

On Wed, 30 Apr 2025 15:28:18 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> We want to obtain a value that is larger than `lo`, has the bit at a certain position set and all bits after that unset. It is aligning `lo` up to `alignment`. This is the standard operation for alignment when we know that `lo` is unaligned.
>
>> We want to obtain a value that is larger than lo, has the bit at a certain position set and all bits after that unset.
> 
> So much I knew already, but could still not understand the formula 😅 
> 
>> This is the standard operation for alignment when we know that lo is unaligned.
> 
> To me it is still not "standard". And you use a similar formula elsewhere, so maybe it could be helpful to explain if in more detail somewhere?
> 
> - if `first_violation == 0`: `alignment = 100..00 = -alignment`. So if `lo >= alignment` -> `lo & -alignment = 100..000`, and `new_lo = 0`, we have an overflow it seems? I guess that would make sense. And if `lo < alignment`, the result is rounded up to `100..000`, also good.
> - if `first_violation > 0`: `alignment = 0..010..0`. So `-alignment = 1..110..0`. Now you could probably continue with arguing about the bits of `lo`, and continue that way in a case distinction.
> 
> To me this seems less than immediately clear or trivial. Maybe I'm just missing some "standard" math, that is well possible 😉

Maybe the thing you are missing here is that if a value `v` is a power of 2, then its negation `-v` will have all the bit set upto the location that is set in `v`. E.g. `4 = 0x00...0100 -> -4 = 0b11...1100`. So `lo & -alignment` is the act of unsetting all the bits after the set bit in `alignment`. A.k.a rounding down according to `alignment`. So if you want to round up you just add `alignment` since `lo` is known to not be divisible by `alignment`.

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

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