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

[Bhavana Kilambi]

On Thu, 13 Feb 2025 01:47:10 GMT, Xiaohong Gong <xgong 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          1024  thrpt  30    82.01x       81.74x      82.153x
> LongMaxVector...

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?

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

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