RFR: 8343689: AArch64: Optimize MulReduction implementation [v3]

[Xiaohong Gong]

On Mon, 30 Jun 2025 12:05:08 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2087:
>> 
>>> 2085:   assert(vector_length_in_bytes > FloatRegister::neon_vl, "ASIMD impl should be used instead");
>>> 2086:   assert(vector_length_in_bytes <= FloatRegister::sve_vl_max, "unsupported vector length");
>>> 2087:   assert(is_power_of_2(vector_length_in_bytes), "unsupported vector length");
>> 
>> Better to compare with `MaxVectorSize`.
>> 
>> I suggest using `assert(length_in_bytes == MaxVectorSize, "invalid vector length");` and putting this assertion in `aarch64_vector.ad` file, i.e. inside the matching rule.
>
> Why is it better that way? Currently the assertions check that we end up here if there computations that can be done only  using SVE (length > neon && length <= sve). What would happen if a user operates 256b VectorAPI vectors on a 512b SVE platform?

That would be the operations with partial vector size valid. For such cases, we will generate a mask in IR level, and a `VectorBlend` will be generated for this reduction case. Otherwise the result will be incorrect. So the vector size should be equal to MaxVectorSize theoretically.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23181#discussion_r2176524365