Contains RVV implementations for the following Neon instructions: 

`abal`, `abdl_high`, `addw`, `addw_high`, `bcax`, `bic`, `cadd_rot270`, `cadd_rot90`, `cmla_lane`, `cmla_rot180_lane` , `cmla_rot270_lane`, `cmla_rot90_lane`, `combine`, `cvt`, `dot`, `dot_lane`, `dup_n`, `eor`, `ext`, `maxnmv`, `minnmv` , `movl` , `movn` , `qdmull` , `qshlu_n`,  `rnda`,  `rsubhn` , `shl`, `shl_n`, `shll_n`, `shr_n`, `shrn_n`, `sqadd`, `sqrt` 

Contains RVV implementations for the following Neon instructions.

`abs`, `addl`, `addl_high`, `addlv`, `addv`, `cge`, `cgt`, `cle`, `clez`, `clt`, `cnt`, `fma`, `fms`, `fms_n`, `get_high`, `get_low`, `hsub`, `mla`, `mla_n`, `mlal`, `mlal_high`, `mlal_high_n`, `mlal_n`, `mls`, `mls_n`, `mlsl`, `mlsl_high`, `mlsl_high_n`, `mlsl_n`, `qsub`, `qtbl`, `qtbx`, `rbit`, `recpe`, `rev16`, `rev32`, `rev64`, `subl`, `subl_high`, `subw`, `subw_high`, `tbl`, `tbx`

It seems GCC supports _Float16 in C++ on aarch64 since GCC 13, at least
according to my quick tests on godbolt.org.

(It was already supported in C since GCC 7.)

_Float16 on x86 requires SSE2 instruction set to be available.
References:

 * https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
 * https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point

Clang does not support _Float16 on s390x

https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point

Signed-off-by: Zhijin Zeng <zhijin.zeng@spacemit.com>

WebKit project recently imported simde 0.8.2
Since then the build for Aarch64 targeting RPi4 boards has started
giving lot of warnings related to the simde header:

  warning: "__ARM_NEON_FP" is not defined, evaluates to 0 [-Wundef]

Add a check to ensure that __ARM_NEON_FP is defined.

Related: https://bugs.webkit.org/show_bug.cgi?id=273789

Signed-off-by: Zhijin Zeng <zhijin.zeng@spacemit.com>

Signed-off-by: Zhijin Zeng <zhijin.zeng@spacemit.com>

1. For vqdmlal_s16/s32: the doubling result maybe overflow,
so need to use vqaddq_s16/32 to saturate it. As the same with
vqdmlsl_s16/32.

2. The vrdmulh family function need to use vqadd saturating
function to avoid the doubling result overflow.

3. The result of vrshl family function need to keep the sign
bit of the origin data. If a > 0 && b < 0, the result of
(a + (1 << (-b - 1))) maybe overflow into a negative value.
And in gcc/clang, >> means the arithmetic shift left, so it
will get the incorrect sign bit whithout unsigned extend value.
Signed-off-by: Zhijin Zeng <zhijin.zeng@spacemit.com>

Signed-off-by: Zhijin Zeng <zhijin.zeng@spacemit.com>

Co-authored-by: Michael R. Crusoe <crusoe@debian.org>

Many sources claim that M1 processors support SHA2, but even with
"-march=native", apple clang throws erros like

error: always_inline function 'vsha1h_u32' requires target feature 'sha2', but would be inlined into function 'simde_vsha1h_u32' that is compiled without support for 'sha2'

while we figure out the situation in https://github.com/simd-everywhere/simde/issues/1099

vcvth_s16_f16
vcvtah_s16_f16

vcvth_n_s32_f16
vcvth_n_s64_f16
vcvth_n_u32_f16
vcvth_n_u64_f16
vcvth_n_f16_s32
vcvth_n_f16_s64
vcvth_n_f16_u32
vcvth_n_f16_u64

vcvtmh_s16_f16
vcvtms_s32_f32
vcvtmd_s64_f64

vcvtnh_s16_f16

vcvtph_s16_f16
vcvtps_s32_f32
vcvtpd_s64_f64

Above removed due to test failures on real hardware

vcvt_s16_f16
vcvtq_s16_f16
vcvth_n_s16_f16
vcvt_n_s16_f16
vcvtq_n_s16_f16
(fallback implementations call vcvth_s16_f16)

vcvta_s16_f16
vcvtaq_s16_f16
(fallback implementations call vcvtah_s16_f16)

vcvtmq_s32_f32
vcvtm_s32_f32
(fallback implementations call vcvtms_s32_f32)

vcvtmq_s64_f64
vcvtm_s64_f64
(fallback implementations call vcvtmd_s64_f64)

vcvtnq_s16_f16
vcvtn_s16_f16
(fallback implementations call vcvtnh_s16_f16)

vcvtpq_s16_f16
vcvtp_s16_f16
(fallback implementations call vcvtph_s16_f16)

vcvtpq_s32_f32
vcvtp_s32_f32
(fallback implementations call vcvtps_s32_f32)

vcvtpq_s64_f64
vcvtp_s64_f64
(fallback implementations call vcvtpd_s64_f64)

vcvtmq_s16_f16
vcvtm_s16_f16
(fallback implementations call vcvtmh_s16_f16)

https://github.com/llvm/llvm-project/commit/dbeb3d029d8e3120668288a284d0babeb81545fd

* feat : add ci test for RISC-V Vector
* feat : modify types.h for risc-v vector extension
* feat : modify simde utilities for rvv
* feat : modify load & store for risc-v v extension
* feat : modify load & store for risc-v vector
* feat : add and mul neon to rvv
* feat : add rvv CI without zvfh
* feat : add rvv implementation (mul_lane)
* feat : add mulx_lane neon2rvv

- So cast to unsigned int before flipping sign, and then cast back to a signed int

LLVM 19 is making this more prominant: https://github.com/llvm/llvm-project/issues/82112#issuecomment-1956469212
But this was already visible in earlier clang versions with `-O2` https://github.com/simd-everywhere/simde/issues/901

- gh-actions: resume testing emscripten using the 'tip of tree' ("tot") builds.
- gh-actions: add clang-17 "-O2" build to confirm the fix

Verified with godbolt:

- when using clang 17, it's 170000: https://godbolt.org/z/MTzb8va48 https://releases.llvm.org/17.0.1/tools/clang/docs/ReleaseNotes.html#attribute-changes-in-clang
- when using clang 16, it's 160000: https://godbolt.org/z/8avxvq7rj https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html#attribute-changes-in-clang

https://releases.llvm.org/13.0.0/tools/clang/docs/DiagnosticsReference.html#waix-compat

Improve and simplify implementation of simde_mm512_add_epi32 as follows:

(1): Remove the explicit SVE implementation. For SVE vector lengths of
VL={128, 256}, this explicit vector length agnostic (VLA) SVE loop
performs significantly worse than the Neon equivalent, which can be
executed using fewer instructions. This sequence of SVE intrinsics is
also malformed according to clang, so it fails to compile altogether.

(2): Preferentially use GCC's vector extension if available, instead of
repeated calls to simde_mm256_add_epi32. There are a couple of reasons
for this:

(a) The added indirection results in worse code generation. See the code
    generation attached to commit message for an example with GCC 13.

(b) GCC's vector extension is an easier optimization target for
    compilers, allowing them to appropriately output performant code
    generation depending on their own internal cost & tuning models.
    See the snippets attached to commit message for an example of
    improved code-gen in a vector length specific (VLS) context.

This brings the implementation of simde_mm512_add_epi32 back in line
with other similar AVX512 intrinsics, such as simde_mm512_sub_epi32 and
simde_mm512_mul_ps.

Fixes #980.

An example of code-gen difference is shown below. Source is a function
containing a single call to simde_mm512_add_epi32.

Compiler: GCC 13.2.0
Compile flags: -O3 -march=armv8-a

Before this patch:
   0:    ld1    {v28.16b-v31.16b}, [x0]
   4:    sub    sp, sp, 0x90
   8:    ld1    {v24.16b-v27.16b}, [x1]
   c:    add    x2, sp, 0x3f
  10:    and    x2, x2, 0xffffffffffffffc0
  14:    add    x0, x2, 0x40
  18:    add    x1, x2, 0x20
  1c:    add    v24.4s, v24.4s, v28.4s
  20:    add    v25.4s, v25.4s, v29.4s
  24:    add    v26.4s, v30.4s, v26.4s
  28:    add    v27.4s, v31.4s, v27.4s
  2c:    stp    q24, q25, [x2, 64]
  30:    ld1    {v28.16b, v29.16b}, [x0]
  34:    stp    q26, q27, [x2, 64]
  38:    ld1    {v30.16b, v31.16b}, [x0]
  3c:    st1    {v28.16b, v29.16b}, [x2]
  40:    st1    {v30.16b, v31.16b}, [x1]
  44:    ld1    {v28.16b-v31.16b}, [x2]
  48:    st1    {v28.16b-v31.16b}, [x8]
  4c:    add    sp, sp, 0x90
  50:    ret

With this patch:
   0:    ld1    {v28.16b-v31.16b}, [x0]
   4:    ld1    {v24.16b-v27.16b}, [x1]
   8:    add    v24.4s, v28.4s, v24.4s
   c:    add    v25.4s, v29.4s, v25.4s
  10:    add    v26.4s, v30.4s, v26.4s
  14:    add    v27.4s, v31.4s, v27.4s
  18:    st1    {v24.16b-v27.16b}, [x8]
  1c:    ret

Another example of code-gen difference is shown below, targeting an SVE
enabled microarchitecture with a 512-bit vector length in a vector
length specific (VLS) context.

Compiler: GCC 13.2.0
Compile flags: -O3 -march=armv8-a+sve -msve-vector-bits=512

Before this patch:
   0:    sub     sp, sp, 0xf0
   4:    mov     x2, 0x10 // 16
   8:    ptrue   p6.b, vl64
   c:    add     x4, sp, 0x3f
  10:    mov     x3, x2
  14:    ld1d    {z31.d}, p6/z, [x0]
  18:    and     x4, x4, 0xffffffffffffffc0
  1c:    ld1d    {z30.d}, p6/z, [x1]
  20:    ptrue   p7.s, vl16
  24:    add     x6, x4, 0x40
  28:    add     x5, x4, 0x80
  2c:    st1d    {z30.d}, p6, [x4]
  30:    st1d    {z31.d}, p6, [x4, 1, mul vl]
  34:    nop
  38:    nop
  3c:    nop
  40:    add     x0, x4, x2, lsl 2
  44:    add     x1, x6, x2, lsl 2
  48:    ld1w    {z30.s}, p7/z, [x0, -1, mul vl]
  4c:    ld1w    {z31.s}, p7/z, [x1, -1, mul vl]
  50:    add     x0, x5, x2, lsl 2
  54:    add     z30.s, z31.s, z30.s
  58:    st1w    {z30.s}, p7, [x0, -1, mul vl]
  5c:    whilelo p7.s, x2, x3
  60:    add     x2, x2, 0x10
  64:    b.ne    40 // b.any
  68:    ptrue   p7.b, vl64
  6c:    ld1d    {z31.d}, p7/z, [x4, 2, mul vl]
  70:    st1d    {z31.d}, p7, [x8]
  74:    add     sp, sp, 0xf0
  78:    ret

With this patch:
   0:    ptrue   p0.b, vl64
   4:    ld1d    {z0.d}, p0/z, [x0]
   8:    ld1d    {z1.d}, p0/z, [x1]
   c:    add     z0.s, z0.s, z1.s
  10:    st1d    {z0.d}, p0, [x8]
  14:    ret