RFR: 8279651: [vectorapi] Implement the missing intrinsics for casting from integrals on x64 [v8]

[Vladimir Ivanov]

On Tue, 18 Jan 2022 15:27:21 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4150:
>> 
>>> 4148:   jmp(done);
>>> 4149: 
>>> 4150:   bind(slow_path);
>> 
>> How common the slow path is expected to be?
>> Depending on the frequency, it may be sensible to extract the code into a stub shared across all the vector casts in generated code.
>
> Good idea, do you know how to properly save the state of a `xmm` register? Currently I can only see using x86_32 approach which does not need to touch the `xmm` registers.

Another option is to pass vector value in register (use vector calling conventions in the stub, e.g. `xmm0`; take a look at `CallLeafVector` used for SVML stubs). It would require fixed location for the vector argument. You can achieve that with additional temporary operand (`rxmm0 tmp`).

>> src/hotspot/cpu/x86/x86.ad line 6951:
>> 
>>> 6949: 
>>> 6950: instruct vcastStoX_evex(vec dst, vec src) %{
>>> 6951:   predicate((Matcher::vector_element_basic_type(n) == T_BYTE && UseAVX > 2 && VM_Version::supports_avx512vlbw()) ||
>> 
>> The following code is redundant:
>> 
>>   switch (to_elem_bt) {
>>       case T_BYTE:
>>         if (!VM_Version::supports_avx512vl()) {
>>           vlen_enc = Assembler::AVX_512bit;
>>         }
>
> Yes it is. However, the intention of this code seems that `vpmovwb` is promoted to `AVX_512bit` when avx512vl is not available, and the predicate is too restrictive. I think this needs a closer look.

AVX512VL support always comes along with AVX512BW in Intel CPUs. Xeon Phis didn't support VL, but they didn't support BW as well. So, it's safe to assume that BW implies VL and use `VM_Version::supports_avx512vlbw()` instead of `VM_Version::supports_avx512bw()`. It makes the aforementioned code effectively dead.

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

PR: https://git.openjdk.java.net/jdk/pull/7002