silk: Add Arm NEON silk_VAD_GetSA_Q8

[czoli1976]

Summary

silk_VAD_GetSA_Q8 had an x86 SSE4.1 implementation but no Arm one, even though it runs on every SILK/hybrid frame in the default (float) build. This adds a NEON version, mirroring the SSE4.1 one.

What's vectorised

The per-subframe energy sum-of-squares — (X[i] >> 3)^2 accumulated in int32 — 8 samples per iteration via vshrq_n_s16 + paired vmlal_s16 (low/high), with a scalar tail and a horizontal vaddvq_s32. Everything else (analysis filterbank, noise estimation, SNR/tilt) is identical to the C reference, exactly as the SSE4.1 version does.

• Bit-exact with silk_VAD_GetSA_Q8_c (exact integer sum of squares, no overflow), validated by the existing OPUS_CHECK_ASM full-encoder-state memcmp.
• As on x86, silk_VAD_GetNoiseLevels becomes exported (instead of static inline in VAD.c) when NEON is enabled, so the kernel can call it.

Dispatch / wiring

Uses the existing OVERRIDE_silk_VAD_GetSA_Q8 hook: a new silk/arm/VAD_arm.h provides the PRESUME (direct call) and RTCD (SILK_VAD_GETSA_Q8_IMPL table in arm_silk_map.c) dispatch, mirroring silk/x86/main_sse.h. The source is added to the common SILK_SOURCES_ARM_NEON_INTR group, which is already wired in autotools / CMake / Meson — so no build-system changes are needed.

Numbers (Apple M4)

• Microbench of the vectorised loop at the real subband lengths (10–80 samples): ~1.1–1.7× over scalar.
• End-to-end within run-to-run noise (VAD is a small per-frame cost), bitstream unchanged (bit-exact).
• Full meson test suite passes.

This is the last of the silk-side x86-has-it/ARM-doesn't parity gaps that runs in the default build.

[lpi]

Tested head: 0f4f92500c7af1acc3caf9f68b54328dc281c70b.

With #483 applied on top of #503, the approximate combined production-c10 encoder improvement versus stock is +4.0159% thread CPU / +4.0195% wall. Positive means faster/lower per-call cost; negative means slower. These are compounded cross-run estimates from the direct #503-versus-stock result and the incremental #483-versus-#503 result, not a direct stock arm.

#483 itself measured -0.0578% CPU / -0.0658% wall versus #503, so it did not improve encoding over #503. Route instrumentation confirmed that the modified VAD path executed in encode/re-encode, and the output/state checks were exact.

Separately, the unguarded AArch64-only vaddvq_s32 breaks ARMv7 compilation and should be guarded if ARMv7 remains supported.

[czoli1976]

Acknowledged the ARMv7 build break you flagged (@lpi): the AArch64-only vaddvq_s32 at the per‑subframe horizontal reduction has been replaced with a portable vpadd_s32 + lane‑extract pattern (commit 1125bbaa). It compiles cleanly on both ARMv7 and AArch64 and produces identical addp codegen on AArch64 (zero perf impact on the reduction, which runs once per 8‑sample block, not in the inner MAC loop).

Re the −0.0578% incremental — that is within run‑to‑run noise here too (the combined #503+#483 result of +4.0% is solid). Will keep an eye on it but no further action needed on the code.

Full analysis of both your review points below:

1. The review, summarized

• ✅ VAD path executes in encode/re‑encode; output/state checks are exact (bit‑identical)
• ✅ Combined Reduce state-copy pressure in the hottest SILK mode #503+silk: Add Arm NEON silk_VAD_GetSA_Q8 #483 vs stock: +4.02% thread CPU / +4.02% wall
• ⚠️ silk: Add Arm NEON silk_VAD_GetSA_Q8 #483 vs Reduce state-copy pressure in the hottest SILK mode #503 alone: −0.0578% (noise; within measurement error)
• ❌ ARMv7 build break: vaddvq_s32 is AArch64‑only (now fixed)

2. Is the review positive? Yes. lpi confirmed the VAD changes work correctly and the combined improvement is solid +4%. The only actionable items were the ARMv7 guard (fixed) and the noise‑level perf note (not a blocker).

3. The fix
vaddvq_s32 (AArch64 addp) → vpadd_s32 + vget_lane_s32 (portable). See the squash commit for the diff.

[czoli1976]

@lpi do you think it is fine now ? also the ARM v7 is covered