RFR: 8282162: [vector] Optimize vector negation API

[Xiaohong Gong]

On Sat, 19 Mar 2022 02:34:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
>> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
>> 
>> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
>> 
>> So with this patch, the following transformations are applied:
>> 
>> For non-masked negation with NEON:
>> 
>>   movi    v16.4s, #0x0
>>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
>> 
>> and with SVE:
>> 
>>   mov z16.s, #0
>>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
>> 
>> For masked negation with NEON:
>> 
>>   movi    v17.4s, #0x1
>>   mvn v19.16b, v18.16b
>>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>>   add v19.4s, v20.4s, v17.4s
>>   mov v18.16b, v16.16b
>>   bsl v18.16b, v19.16b, v20.16b
>> 
>> and with SVE:
>> 
>>   mov z16.s, #-1
>>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>>   eor z18.s, p0/m, z18.s, z16.s
>>   add z18.s, p0/m, z18.s, z17.s
>> 
>> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
>> 
>> NEON:
>> Benchmark                Gain
>> Byte128Vector.NEG        1.029
>> Byte128Vector.NEGMasked  1.757
>> Short128Vector.NEG       1.041
>> Short128Vector.NEGMasked 1.659
>> Int128Vector.NEG         1.005
>> Int128Vector.NEGMasked   1.513
>> Long128Vector.NEG        1.003
>> Long128Vector.NEGMasked  1.878
>> 
>> SVE with 512-bits:
>> Benchmark                Gain
>> ByteMaxVector.NEG        1.10
>> ByteMaxVector.NEGMasked  1.165
>> ShortMaxVector.NEG       1.056
>> ShortMaxVector.NEGMasked 1.195
>> IntMaxVector.NEG         1.002
>> IntMaxVector.NEGMasked   1.239
>> LongMaxVector.NEG        1.031
>> LongMaxVector.NEGMasked  1.191
>> 
>> X86 (non AVX-512):
>> Benchmark                Gain
>> ByteMaxVector.NEGMasked  1.254
>> ShortMaxVector.NEGMasked 1.359
>> IntMaxVector.NEGMasked   1.431
>> LongMaxVector.NEGMasked  1.989
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896
>
> src/hotspot/share/opto/vectornode.cpp line 141:
> 
>> 139:       case T_BYTE:
>> 140:       case T_SHORT:
>> 141:       case T_INT: return Op_NegVI;
> 
> Why not add `Op_NegVB` for `BYTE` and `Op_NegVS` for `SHORT`?
> Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector?

The compiler can get the real type info from `Op_NegVI` that can also handle the `BYTE ` and `SHORT ` basic type. I just don't want to add more new IRs which also need more match rules in the ad files.

> Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector?

>From the benchmark results I showed in the commit message, I didn't see not any performance drop for byte/short.  Thanks!

> src/hotspot/share/opto/vectornode.cpp line 1635:
> 
>> 1633: }
>> 1634: 
>> 1635: Node* NegVINode::Ideal(PhaseGVN* phase, bool can_reshape) {
> 
> Much duplication in `NegVINode::Ideal` and `NegVLNode::Ideal`.
> Is it possible to refactor the implementation?

Yeah, maybe we need a superclass for `NegVINode` and `NegVLNode`. Thanks!

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

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