[rich-murphey]

On x86 builds with SQLITE_VEC_ENABLE_AVX, L2 distance uses l2_sqr_float_avx() but cosine distance still runs the scalar loop in distance_cosine_float(). NEON has cosine_float_neon(); AVX had no counterpart. For a cosine vec0 table, this makes cosine queries the slow path on x86.

What changed

• cosine_float_avx(): 16 floats per step into two independent sets of dot, |a|² and |b|² accumulators, so the loop is not bound by FP-add latency. It uses _mm256_fmadd_ps when the build has __FMA__ and mul+add otherwise, so the existing -mavx -mavx2 flags in the Makefile build it unchanged. The tail (fewer than 16 elements) is finished in scalar code, so every dimension count is handled.
• distance_cosine_float() dispatches to it for 16 or more dimensions, behind the existing SQLITE_VEC_ENABLE_AVX flag. The function signature and the scalar path are unchanged.
• test_distance_cosine_float() in tests/test-unit.c checks lengths 15, 16, 17, 31, 33, 47, 384 and 389 against a double-precision reference, within 1e-5. Dropping the tail loop makes it fail.

Tests

• make test-loadable: 239 passed, 66 skipped, on the default AVX build and on an OMIT_SIMD=1 build; same counts as main.
• make test-unit: does not compile on main (Fix test-unit.c so the C unit tests compile and pass #305 fixes that). With Fix test-unit.c so the C unit tests compile and pass #305 merged locally, it passes on the AVX build, an AVX+FMA build (-mfma) and a scalar build.
• No new compiler warnings under the loadable target's -Wall -Wextra.

Benchmark

AMD EPYC 7351P (Zen 1), GCC, -O3 -mavx -mavx2 (Makefile defaults), pinned to one core with its SMT sibling idle. 304,971 random unit vectors, float[384], k = 400, median of 15 queries through the Python sqlite3 module. The host had other load, so the end-to-end rows vary about ±10% between runs.

	main	this PR
kernel only: distance_cosine_float() over all rows, in memory	126.5 ms	35.9 ms	3.5×
same, cache-resident (2,000 rows), per row	407 ns	90 ns	4.5×
vec0 cosine KNN, k=400	571 ms	466 ms	1.2×
vec0 cosine KNN, k=400, with #337's heap	298–328 ms	198–234 ms	1.4–1.5×
vec_distance_cosine() … ORDER BY … LIMIT 400	636 ms	513 ms	1.2×

With -mfma the kernel row is 34.2 ms. KNN results are identical to main (recall@400 = 1.000 on every build).

On main, vec0 KNN time is mostly top-k selection, which is why the kernel's 3.5× shows up as 1.2× there. In an earlier measurement on the same machine and data shape inside an application, with #337's heap top-k, exact vec0 KNN went from 194 ms to 87 ms (2.2×) and the vec_distance_cosine scan from 635 ms to 344 ms (1.8×); vec0 with the existing AVX L2 was 92 ms there.

Related

• Independent of Select each chunk's k nearest rows with the min_idx() heap #337 (heap top-k): no shared code, either can land first, and they merge cleanly. The gains add up, as the table shows.
• Complements Linux/macOS builds bake AVX/AVX2 based on the build machine's CPU, so 0.1.10-alpha wheels SIGILL on older x86_64 #302: it only touches code already compiled under SQLITE_VEC_ENABLE_AVX, so it adds no new ISA requirement beyond what that flag already implies, and whatever Linux/macOS builds bake AVX/AVX2 based on the build machine's CPU, so 0.1.10-alpha wheels SIGILL on older x86_64 #302/Fix SIGILL on pre-AVX x86_64: function-level target attributes + runtime CPU detection #307 settles for selecting AVX at build or run time applies to it too.
• Sum cosine distances and vec_normalize() in double #338 (double-precision cosine sums) merges cleanly with this textually, but not semantically: with both applied, test_vec_distance_cosine_extreme_magnitudes from Sum cosine distances and vec_normalize() in double #338 fails on an AVX build, because this kernel sums in float32 as l2_sqr_float_avx() does and as cosine_float_neon() does on main. If Sum cosine distances and vec_normalize() in double #338 lands first, I can widen this kernel to __m256d sums the same way Sum cosine distances and vec_normalize() in double #338 does for NEON; if this lands first, Sum cosine distances and vec_normalize() in double #338 would need to cover the AVX kernel.