On Thu, 25 Sep 2025 15:58:27 GMT, Jatin Bhateja <[email protected]> wrote:
>> The change looks good, but I wonder: >> >> - if it makes sense to have some kind of IR tests (i.e., it's folded away >> when unneeded, when the input is a constant, ...)? >> - whether the explanation could be simplified: Assuming a correct >> implementation of the KnownBits canonicalization, we can argue >> - `_zeroes` has the bits set that are known to be always 0. So >> `BitsPer<Type> - popCount(x)` gives you an upper limit of how many bits >> *might* be 1. And `BitsPer<Type> - popCount(_zeroes)` is equivalent to >> `popCount(~_zeroes)`. >> - `_ones` has the bits set that are known to be always 1. Trivially, >> `popCount(_ones)` is a valid lower bound. >> - The rest repeats how `adjust_bits_from_unsigned_bounds` works, but >> that's not specific to the popcount nodes. > > Hi @SirYwell , @chhagedorn , @eme64 , I have addressed your comments. Let me > know if this is good to land in. Hi @jatin-bhateja, sorry for a spurious comment but I wish to ask about the status of [lworld+vector](https://github.com/openjdk/valhalla/tree/lworld%2Bvector) in project Valhalla - It makes use of Unsafe.makePrivateBuffer and finishPrivateBuffer, which is outdated in the current Value Objects model (the larval bit will be gone). I just wonder if I can proceed with the removal here https://github.com/openjdk/valhalla/pull/1593, or if I should keep these legacy APIs for further vector work. (FYI we can probably migrate to Unsafe.allocateInstance to do the same, as in Method handles) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27075#issuecomment-3335032730
