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

[Quan Anh Mai]

On Mon, 17 Jan 2022 19:29:24 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix
>
> Overall,

@iwanowww Thanks for your reviews, I think I will update the PR this weekend. In the meantime, I would reply to your concerns.

The condition for a vector node to be generated is that

    input shape supported  && // this is implicit, happen for example at the intrinsic of VectorSupport.convert, I think we should make it more explicit
    output shape supported && // check at the start of Matcher::match_rule_supported_vector
    special rules             // List explicitly in the method

Detailed logic for each circumstance will be responded separately.

Thank you very much.

> 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.

> src/hotspot/cpu/x86/x86.ad line 6881:
> 
>> 6879: instruct vcastBtoX(vec dst, vec src) %{
>> 6880:   predicate(UseAVX > 1 ||
>> 6881:             Matcher::vector_element_basic_type(n) != T_FLOAT ||
> 
> Before the change, the implicit predicate was `bt != T_DOUBLE && size_in_bits == 256 && UseAVX < 2`. 
> 
> Why do you check `T_FLOAT` then?
> Why `Matcher::vector_length_in_bytes(n) < 32` and not `Matcher::vector_length_in_bytes(n) != 32`?

Because on AVX1, 256-bit integral vectors are not supported, so the only candidates for a 256-bit vector here are float and double.

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

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