[vectorIntrinsics] RFR: 8283709: Add x86 back-end implementation for bit BIT_COUNT operation [v7]

[Sandhya Viswanathan]

On Fri, 8 Apr 2022 19:14:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 8643:
>> 
>>> 8641:   format %{ "vector_popcount_integral_evex $dst, $src" %}
>>> 8642:   ins_encode %{
>>> 8643:     assert(UsePopCountInstruction, "not enabled");
>> 
>> UsePopCountInstruction is ambiguous now? subword vs int/long depend on different platform feature so cannot be combined?
>
> It a JVM flag, fall back code is still  based on Integer.bitCount and Long.bitCount APIs,  if the flag is turned off we do not intrinsify these scalar APIs.  match_rule_supported which is called through vector inline expander is also sensitive to this flag.

match_rule_supported is explicitly checking for avx512popcntdq and avx512bitalg feature. UsePopCountInstruction is only set based on avx512popcntdq feature.

>> src/hotspot/cpu/x86/x86.ad line 8709:
>> 
>>> 8707:     // special handling should be removed.
>>> 8708:     if (bt == T_INT) {
>>> 8709:       __ evpmovqd($dst$$XMMRegister, $dst$$XMMRegister, vlen_enc);
>> 
>> why are we using evex instruction for avx path?
>
> AVX512 targets not supporting AVX512_POPCOUNTD feature can still have 64 byte vector operation, since long pop-count was only enabled for 512 bit vectors uptill now hence a down-casting EVEX instruction worked fine.

I see you fixed this is in your review comment resolution by adding a check for avx512vl  around this instruction and a separate instruction generation for non avx512 path, thanks.

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

PR: https://git.openjdk.java.net/panama-vector/pull/185