Proposed removal of MIPS DSPr2 SIMD extensions

[DRC]

In 2021, MIPS Technologies deprecated the MIPS architecture in favor of
RISC-V. The DSPr2 SIMD instruction set that libjpeg-turbo supports was
already outdated and had been superseded by the MSA instruction set
(which was never widely implemented and is now deprecated along with the
MIPS architecture.) Referring to
https://github.com/libjpeg-turbo/libjpeg-turbo/issues/835,
libjpeg-turbo's DSPr2 SIMD extensions have known limitations, including:

- Three outright bugs (although it's unclear whether one of those bugs
exists outside of QEMU)

- Eight modules that are not big-endian-compatible
(https://libjpeg-turbo.org/About/SIMDCoverage)

- No support for 64-bit

Thus, their usefulness was already limited to a narrow subset of MIPS
CPUs, and they didn't work properly in all cases even on those CPUs. I
have never had a MIPS dev/test platform, so I have no way to address or
validate the aforementioned issues/limitations except to test them with
QEMU.

Referring to https://github.com/libjpeg-turbo/libjpeg-turbo/pull/408 and
https://gist.github.com/ssvb/ba785950cd8d931e2db034f7c70a1993,
performance is a mixed bag, since some of the DSPr2 modules in
libjpeg-turbo are implemented with few or no actual DSPr2 instructions.
(In some cases, the compiler can produce code from a C module that
performs as well as or better than the corresponding DSPr2 assembly
module.) In general, when using the "fast" DCT/IDCT (legacy feature),
the speedup from DSPr2 is about 20-40%. It is less when using the
accurate DCT/IDCT. That is considerably less compelling than the 2-7x
speedup that can be obtained with other CPUs and SIMD instruction sets.

This serves as a public announcement that, if no one steps forward to
fix, validate, and maintain the DSPr2 SIMD extensions by the time
libjpeg-turbo 3.2 is finalized (mid-2026), those extensions will be
removed. Regardless, the DSPr2 SIMD extensions will continue to be
maintained in libjpeg-turbo 3.1.x and prior on a break/fix basis, with
the understanding that they are currently broken.

Again referring to
https://github.com/libjpeg-turbo/libjpeg-turbo/issues/835, I will accept
PRs that implement:

1. Fixes for any of the aforementioned issues/limitations (fixes could
be integrated with 3.1.x and other stable branches)

2. 64-bit support (possibly integrable with the stable branches as well,
depending on how disruptive it is)

3. An intrinsics implementation of the extensions

Fixing/validating the aforementioned outright bugs would be the minimum
necessary to signal that someone cares enough about these extensions to
justify keeping them.

DRC