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

erifan duke at openjdk.org
Thu Jul 31 08:09:57 UTC 2025


On Thu, 31 Jul 2025 07:27:43 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> 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.)

@SirYwell, thanks for your explanation, now I got your points. It's a good idea, with your suggestions, this optimization may apply to more cases. As you said, the KnownBits part is hard to test right now, so that's it for now.

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

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


More information about the hotspot-compiler-dev mailing list