RFR: 8334505: RISC-V: Several tests fail when MaxVectorSize does not match VM_Version::_initial_vector_length

[Gui Cao]

On Wed, 19 Jun 2024 08:07:40 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> HI, It's possible to specify a MaxVectorSize which is not equal to VM_Version::_initial_vector_length on RISC-V. For example, it could happen on Banana-Pi that MaxVectorSize equals 16, while VM_Version::_initial_vector_length is 32. This may lead to several jtreg test failures, see jbs issue for exception information.
>> 
>> The reason for this problem is that when spill vector registers into memory, the whole width of the register is used incorrectly, and MaxVectorSize should be used to handle the number of elements spill.
>> 
>> https://github.com/openjdk/jdk/blob/326dbb1b139dd1ec1b8605339b91697cdf49da9a/src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp#L133-L136
>> 
>> PR propose to simply set MaxVectorSize to VM_Version::_initial_vector_length for the following reasons:
>> 1. The CSR_VLENB register of RISC-V is read-only, we can't change it to MaxVectorSize like like aarch64.
>> 2. It does not make sense to me to set MaxVectorSize to a value smaller than VM_Version::_initial_vector_length in the real world, which might bring negative impact on performance.
>> 3. If MaxVectorSize equals to VM_Version::_initial_vector_length, then we can make use of vs1r_v/vl1r_v when saving and restoring vector registers, which avoids the need to control the number of elements with vsetvli.
>> 
>> After this patch, MaxVectorSize always equal to VM_Version::_initial_vector_length:
>> 
>> zifeihan at plct-c8:~/jdk/build/linux-riscv64-server-fastdebug/jdk/bin$ ./java -XX:MaxVectorSize=16 -XX:+PrintFlagsFinal -version |grep MaxVectorSize
>> OpenJDK 64-Bit Server VM warning: MaxVectorSize is set to 32 on this platform
>>      intx MaxVectorSize                            = 32                                     {C2 product} {command line}
>> openjdk version "24-internal" 2025-03-18
>> OpenJDK Runtime Environment (fastdebug build 24-internal-adhoc.zifeihan.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 24-internal-adhoc.zifeihan.jdk, mixed mode)
>> zifeihan at plct-c8:~/jdk/build/linux-riscv64-server-fastdebug/jdk/bin$ ./java -XX:MaxVectorSize=32 -XX:+PrintFlagsFinal -version |grep MaxVectorSize
>>      intx MaxVectorSize                            = 32                                     {C2 product} {command line}
>> openjdk version "24-internal" 2025-03-18
>> OpenJDK Runtime Environment (fastdebug build 24-internal-adhoc.zifeihan.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 24-internal-adhoc.zifeihan.jdk, mixed mode)
>> zifeihan at plct-c8:~/jdk/build/linux-riscv64-server-fastdebug/jdk/bin$ ./ja...
>
> Yeah, most of the related RISC-V code was written under the assumption that MaxVectorSize matches `vlenb` CSR (the vector register length in bytes). I agree it will be safer to have this change for now. Also I don't think a MaxVectorSize value smaller than `vlenb` would work if we want to experiment with vector register groups (LMUL > 1) some day for C2 especially when we come to vector reduction operations.

@RealFYang : Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19785#issuecomment-2190227009