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