x86 sse2: fix overflow error detected by clang scan-build in simde_mm_srl_epi{16,32,64} when count is too high

UQRSHL was incorrect in several ways, and did not match hardware.
Shift checks for saturating were not modified from the signed
version, leading to incorrect behavior at (untested) edge cases.

Further, for the 32-bit and 64-bit versions, the rounding math was
incorrect with a -32 or -64 shift, and did not match hardware.  This
has been special cased to do the proper thing at the edge case.  The
core issue is overflowing the stock 32-bit or 64-bit types used at
the limit.

Tests have been modified with substantially increased test cases to
properly exercise these changes.  The new tests should cause failures
in the unsigned cases without the modified code, and should pass with
the changes.  Additional signed tests were added to handle the edge
cases, though no incorrect behavior was observed on those.

Test cases generated on a Google C4a ARMv8.4 machine.

Formatting normalization.

Put similar functions in the same order.

Replace the last usage of SIMDE_ARCH_ARM_CHECK(8, n) with feature
checks.
Co-Authored-By: Michael R. Crusoe <crusoe@debian.org>

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312#c2

Function prototype has two parameters:
simde_vqdmulhs_s32(int32_t a, int32_t b)

Native define only had one.  This does not build.
Tests only ever called with the simde_ prefix.

1. fix typo:
  Modify simde_mm256_bslli_epi128 to simde_mm256_bsrli_epi128.
2. fix loongarch compiler errors:
  At present, the instructions like slli/srli/srai on loongarch
  only accept immediate constant values for shit count, so in order to
  avoid compiler errors in the build process, we need to use
  sll/srl/sra version instead. In the feature, if the compiler
  supports the formers, we can restore them.

At present, the instructions like slli/srli on loongarch only
accept immediate constant values for shit count, so in order
to avoid compiler errors in the build process, we need to use
sll/srl version instead. In the feature, if the compiler
supports the formers, we can restore them.

The only reason the SSE code for qrdmulh passed is because the edge
cases were not included in the tests unless SSE was disabled.  The
INT16_MIN * INT16_MIN case ought result in INT16_MAX - and it does,
in the fallback code.  It does not, in the SSE code, which is
what will typically be used on x86 hardware.  Saturating code not
handling edge cases is simply wrong.

* Fix qdmlal instructions

qdmlal instructions were implemented without saturation.
This has been fixed by utilising existing SIMDe saturating mult and add instructions.
Unit tests have been updated to test for all possible saturation cases.

- Fix qdmlal, qdmlal_n, qdmlal_lane,  qdmlal_high, qdmlal_high_n and qdmlal_high_lane
- Update unit tests for qdmlal, qdmlal_n, qdmlal_lane, qdmlal_high, qdmlal_high_n, qdmala_high_lane

Change-Id: I8d0d8cfba3f8d5203f2028efbe74b00c51485c61

* arm neon qdmlal_high_lane: unroll SIMDE_CONSTIFY for testing macro implemented functions with MSVC

---------
Co-authored-by: Michael R. Crusoe <michael.crusoe@gmail.com>

The scalar vqshlud_n_s64 function was wrong, and there was no test
case for it (or the scalar 32 bit form).  Add test cases for the
scalar functions (test vectors generated on GCE ARMv9 system),
validate the fix for the 64-bit scalar form.

The qdmlsl instructions were implemented without any saturation.
This has been fixed by utilising existing saturating instructions which
are implemented correctly.

Unit tests have also been updated to test for saturation.

Change-Id: Ia9e5a7bd850bc178920c19e390c17db5a3bfbc4f

UQSHL was wrong in a variety of ways.  Most importantly, it did not
trim off the low byte for the shift as per the instruction spec:
"... shifts the element by a value from the least significant byte
of the corresponding element of the second source register..."
This was not detected in the tests, as the test vectors were limited
to small shift values that did not demonstrate the fault.

Behavior is fixed to be correct, per hardware.  Test vectors are
dramatically expanded, using both the previous small-range values as
well as additional full-range values.  Vectors generated on an ARMv9
system (Google Compute Engine C4A).

The non-vectorized SQDMULL implementation was wrong for 32-bit
inputs.  It incorrectly checked one of the operands to see if the
value would overflow before doubling it, not the result of the
initial multiplication.  It now matches the 16-bit operand version,
and also matches hardware.  A test has been added for the scalar
form of the function, testing a range of values that will saturate
when multiplied and doubled.  This set of test vectors was produced
on an ARMv9 machine (Google Cloud box), failed tests on x86 with the
existing code, and passes with the modified code.

r_.values _is_ being initialized.  The compiler is missing this.

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

Most SIMDe functions have the SIMDE_ or simde_ prefix internally.
Several of the ARM hash functions do not have this prefix, and this
means that the standard names of ROR32/ROL32 can conflict with other
projects using the library.

This is purely a cosmetic change with internal function renaming.  It
changes no external interfaces, simply removes a source of potential
conflict with other projects that have similarly named macros.

Per the ARMv8 manual, the valid range of shifts for the vector SLI
operations is "0 to the element width in bits minus 1."  The existing
SIMDe implementation creates an invalid shift in the case of 0, as
the shifts are (element width - n) - so, for a 0-bit shift on a
64-bit value, the shift is 64.  This is undefined per the C spec, and
leads to compiler warnings on build.

This fix changes the sli_n shift operations to work properly for the
valid range of values, shifting ((element width - 1) - n), with a
modified constant value to generate the same results (7f... instead
of ff...).

While the existing tests all pass with the change, a number of the
tests have been modified (and have new constant values generated) to
properly exercise and demonstrate the "n == 0" shift case.  These
test vectors were generated on an ARMv9 system (Google Compute Engine
C4A system), and pass on x86 hardware as well.

Co-authored-by: Egor Ignatov <egori@altlinux.org>