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)