RFR: 8356760: VectorAPI: Optimize VectorMask.fromLong for all-true/all-false cases [v8]

Hannes Greule hgreule at openjdk.org
Thu Jul 31 07:29:59 UTC 2025


On Wed, 30 Jul 2025 07:06:52 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> erifan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set default warm up to 10000 for JTReg tests
>
> I think there are a few (follow-up?) improvements that can be made:
> 1. Using KnownBits and checking against that rather than requiring a constant in `is_maskall_type`. This is probably a bit difficult to test for now.
> 2. If the range of an input is known to be [-1, 0], we can use that as an input for a MaskAllNode.

> Hi @SirYwell thanks for your suggestions. But I'm not quite understand what you meant, can you elaborate?

@erifan for my first point, knowing that the lower n bits are all 0 or all 1 is enough, i.e., whether `(type->_bits._ones & mask) == mask` (equivalent to `maskAll(true)`) or `(type->_bits._zeros & mask) == mask` (equivalent to `maskAll(false)`). I think we can't test that part well right now because other nodes are missing KnownBits specific Value() implementations.

For the second one, if `type->_lo == -1 && type->_hi == 0`, then we know that the node with this type can be used to represent true or false respectively.

I hacked something together to clarify what I mean: https://github.com/SirYwell/jdk/commit/02e13a479f5e627cc997939865cd1816942d8309

Please let me know if there's still something unclear.

(That said I'm completely fine with the PR as-is, especially as the KnownBits part is hard to test right now.)

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

PR Comment: https://git.openjdk.org/jdk/pull/25793#issuecomment-3138849095


More information about the hotspot-compiler-dev mailing list