On ggml-cpu: tweak ARM_NATIVE_FLAG native baseline arch when extensions need it

[cameronelliott]

Overview

When I tried to compile llama.cpp c841aee on my slightly rare situation,
which is Debian 12 (GCC 12.2.2) running under the Apple Virtualization.framework (under Orbstack tool), it fails to compile.
Issue #27982 contains full version info, and build failure log

In CMakeFile.txt, this raises the base version of ARM_NATIVE_MIN_ARCH given the extensions to work better on GCC 12.x, based upon ARM extension: (dotprod, i8mm, sve, sme)

So, for my hardware I have built and tested: dotprod(8.2-a) and i8mm(8.6-a)

I haven't personally verified these branches: sve2 and sme, but the should be fine given the GGML_CPU_ALL_VARIANTS block in the CMakefile

I tested on GCC 12.2.0 on Debian 12 under an Apple M5 Cpu under the Apple Virtualization.framework

Additional information

This code was provided by Claude Code, under my direction

Claude Code explanation

GGML_NATIVE detects extensions like dotprod/i8mm/sve/sme on the detected CPU and appends them to an -march=armv8-a (or 8.1-a) base. GCC's ACLE intrinsics for these extensions are declared always_inline against a minimum architecture version (e.g. dotprod needs armv8.2-a), so inlining fails with 'target specific option mismatch' when the translation unit's own baseline stays at armv8-a.

Raise the base version token to the minimum the detected extensions require, matching the version thresholds already used by the GGML_CPU_ALL_VARIANTS path in this same file.

## Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES, AI was used to diagnose the issue, and propose this fix.

This was authored by Cameron Elliott, human.

[cameronelliott]

It might be worth posting the benchmarks I ran (some text below is AI output):

Model: gemma-embedding 0.3B Q8_0 (embeddinggemma-300M-Q8_0.gguf)
Test: pp512 (512-token prompt processing, embedding mode)
Command: llama-bench -m <model> -p 512 -n 0 -embd 1 -r 8 -t 9
Machine: Debian GNU/Linux 12 (bookworm), Linux kernel 7.0.14-orbstack aarch64, inside a Linux VM
on Apple Silicon (M5), under OrbStack. GCC 12.2.0. 10 cores.
Git commit under test: c841aeeb8bb2fe417038dadfa9b007cf1a9ef950 (base), bd240f1cf (patched)

Build	Tree	Flags	Result	pp512 (t/s)
CPU-mode (no acceleration)	unpatched	-DGGML_NATIVE=OFF -DGGML_CPU_ARM_ARCH=armv8-a (forced)	builds	1003.58 ± 23.25
Fixed accelerated (this PR)	patched	GGML_NATIVE=ON, default, no extra flags	builds	2092.25 ± 105.68
Unpatched, default	unpatched	GGML_NATIVE=ON, default, no extra flags	fails to compile (exit 2)	N/A
Manual workaround	unpatched	-DGGML_NATIVE=OFF -DGGML_CPU_ARM_ARCH=armv8.6-a+dotprod+i8mm (forced)	builds	2132.86 ± 44.87

This fix gives a 2.08x speedup over CPU-mode, using the default build command, with no extra
flags. It reaches the same speed as the manual workaround (2092 vs 2133 t/s, within noise),
confirming the fix does not need the workaround anymore.

[angt]

apple m4 might be broken because of that, did you check ?