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