RFR: 8349522: AArch64: Add backend implementation for new unsigned and saturating vector operations

[Xiaohong Gong]

On Thu, 13 Feb 2025 11:50:13 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Since PR [1] has added several new vector operations in VectorAPI and the X86 backend implementation for them, this patch adds the AArch64 backend part for NEON/SVE architectures.
>> 
>> The performance of Vector API relative JMH micro benchmarks can improve about 70x ~ 95x on a NVIDIA Grace CPU, which is a 128-bit vector length sve2 architecture,  with different UseSVE options. Here is the gain details:
>> 
>> 
>> Benchmark                  (size)  Mode Cnt -XX:UseSVE=0 -XX:UseSVE=1 -XX:UseSVE=2
>> ByteMaxVector.SADD          1024  thrpt  30    80.69x       79.70x      80.534x
>> ByteMaxVector.SADDMasked    1024  thrpt  30    84.08x       85.72x      85.901x
>> ByteMaxVector.SSUB          1024  thrpt  30    80.46x       80.27x      81.063x
>> ByteMaxVector.SSUBMasked    1024  thrpt  30    83.96x       85.26x      85.887x
>> ByteMaxVector.SUADD         1024  thrpt  30    80.43x       80.36x      81.761x
>> ByteMaxVector.SUADDMasked   1024  thrpt  30    83.40x       84.62x      85.199x
>> ByteMaxVector.SUSUB         1024  thrpt  30    79.93x       79.22x      79.714x
>> ByteMaxVector.SUSUBMasked   1024  thrpt  30    82.93x       85.02x      84.726x
>> ByteMaxVector.UMAX          1024  thrpt  30    78.73x       77.39x      78.220x
>> ByteMaxVector.UMAXMasked    1024  thrpt  30    82.62x       84.77x      85.531x
>> ByteMaxVector.UMIN          1024  thrpt  30    79.04x       77.80x      78.471x
>> ByteMaxVector.UMINMasked    1024  thrpt  30    83.11x       84.86x      86.126x
>> IntMaxVector.SADD           1024  thrpt  30    83.11x       83.07x      83.183x
>> IntMaxVector.SADDMasked     1024  thrpt  30    90.67x       91.80x      93.162x
>> IntMaxVector.SSUB           1024  thrpt  30    83.37x       82.82x      83.317x
>> IntMaxVector.SSUBMasked     1024  thrpt  30    90.85x       92.87x      94.201x
>> IntMaxVector.SUADD          1024  thrpt  30    82.76x       81.78x      82.679x
>> IntMaxVector.SUADDMasked    1024  thrpt  30    90.49x       91.93x      93.155x
>> IntMaxVector.SUSUB          1024  thrpt  30    82.92x       82.34x      82.525x
>> IntMaxVector.SUSUBMasked    1024  thrpt  30    90.60x       92.12x      92.951x
>> IntMaxVector.UMAX           1024  thrpt  30    82.40x       81.85x      82.242x
>> IntMaxVector.UMAXMasked     1024  thrpt  30    90.30x       92.10x      92.587x
>> IntMaxVector.UMIN           1024  thrpt  30    82.84x       81.43x      82.801x
>> IntMaxVector.UMINMasked     1024  thrpt  30    90.43x       91.49x      92.678x
>> LongMaxVector.SADD          102...
>
> src/hotspot/cpu/aarch64/aarch64_vector.ad line 1574:
> 
>> 1572: instruct vsqadd_masked(vReg dst_src1, vReg src2, pRegGov pg) %{
>> 1573:   predicate(UseSVE == 2 && !n->as_SaturatingVector()->is_unsigned());
>> 1574:   match(Set dst_src1 (SaturatingAddV (Binary dst_src1 src2) pg));
> 
> for the masked match rules, should we also add `USE_DEF` effect for `dst_src1` to indicate that this register is both read and written to destructively ? I see that other similarly defined match rules in the ad file do not have this effect defined but I am wondering if this should be done?

Hi @Bhavana-Kilambi , thanks for looking at this PR! And yes, the `dst_src1` should be `USE_DEF` actually, but I think it's safe not adding the effect here manually. The compiler adlc will add the use-def information for each operands when parsing each match rule. You may look at the code details from https://github.com/openjdk/jdk/blob/master/src/hotspot/share/adlc/formssel.cpp#L939 .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23608#discussion_r1955617857