RFR: 8271078: jdk/incubator/vector/Float128VectorTests.java failed a subtest [v3]
Dean Long
dlong at openjdk.java.net
Sat May 14 00:48:50 UTC 2022
On Fri, 13 May 2022 19:48:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
> Why you not using `vextractf128_high` if you need to save 128 uppers bits?
The problem is the low 128 bits for XMM16-XMM31. It requires avx512vl to read/write less than 512 bits. I see two options:
1) Save/restore all 512 bits if avx512vl is not supported.
int vector_len = VM_Version::supports_avx512vl() ? Assembler::AVX_128bit : Assembler::AVX_512bit;
for (int n = 16; n < num_xmm_regs; n++) {
__ evmovdqul(Address(rsp, base_addr+(off++*64)), as_XMMRegister(n), vector_len);
2) Save/restore 64 or 128 bits
if (VM_Version::supports_avx512vlbwdq()) {
__ evmovdqul(Address(rsp, base_addr+(off++*64)), as_XMMRegister(n), Assembler::AVX_128bit);
} else {
__ movsd(Address(rsp, base_addr+(off++*64)), as_XMMRegister(n));
}
1) seems safer. 2) is fragile because it needs to match what `reg_class_dynamic vectorx_reg_vlbwdq` is doing in x86.ad. If reviewers like 2) better then I should probably create a new function, like c2_uses_hi_xmm_vectors(), that both x86.ad and save/restore can use.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8690
More information about the hotspot-compiler-dev
mailing list