32f_log2_32f_neon QA flaky in Ubuntu 25.10 arm g++14 CI

[marcusmueller]

qa_volk_32f_log2_32f

43: Test command: /usr/bin/sh "/home/runner/work/volk/volk/build/lib/volk_32f_log2_32f_test.sh" "/home/runner/work/volk/volk/build/lib"
43: Working Directory: /home/runner/work/volk/volk/build/lib
43: Test timeout computed to be: 10000000
43: 
43: RUN_VOLK_TESTS: volk_32f_log2_32f(vlen=131071, iter=1, tol=5e-06)
43: arch                       |           time |     throughput |  speedup |    max_abs |
43: ---------------------------+----------------+----------------+----------+------------+
43: generic                    |        0.86 ms |    1225.2 MB/s |        - |          - |
43: neon                       |        0.17 ms |    6085.6 MB/s |    4.97x |    5.0e-06 |
43: neonv8                     |        0.16 ms |    6358.1 MB/s |    5.19x |    4.1e-06 | *
43: Best aligned arch          | neonv8 (5.19x)
43: Best unaligned arch        | neonv8 (5.19x)
43: 
43: volk_32f_log2_32f: fail on arch neon
43:   index |        in0 |   expected |     actual |   rel_err |       tol
43: --------+------------+------------+------------+-----------+----------
43:  125098 |     0.2499 |    -2.0004 |    -2.0004 |   2.5e-06 |   5.0e-06
43: ----------------------------------------------------------------------------------------
 43/196 Test  #43: qa_volk_32f_log2_32f ....................................................................................................................***Failed    1.98 se

[marcusmueller]

(note that this issue is not that the test is wrong. I just think it should always be failing this kernel, if at all.)

[marcusmueller]

(also note: volk_neon_intrinsics.h claims of _vlog2_poly_neonv8 that accuracy is no worse than ~1.55e6, which would indicate this failure should not happen, the rest of the kernel is integer math. So, either the comment is wrong, the polynomial coefficients are wrong, or something else is wrong here.)

[marcusmueller]

random thoughts:

• Maybe we should check the coefficients to those calculated with a modern Remez implementation, preferably run on the target hardware to achieve same rounding errors?
  • or maybe we should just not go for Remez but throw optimize(polynomial coefficients, f) at f=max|log2_neon_with_these_coefficients(x) for x in a sensible sampling of all the ~2³¹ positive float32s| to cover the floating point errors introduced by (1-polynomial(x))? That'd certainly be the "think less, brute force" approach, and since close to machine accuracy, the error is not convex at all, we'll probably not actually find the actual optimum, but ~1.55e-6 between our and a libc log2 does seem relatively relaxed.
• a degree-six polynomial seems on [1;2] (for the mantissa) seems pretty solid. I'd be surprised should we need to up the number of coefficients.
• why is neon different at all from neonv8? The polynomial coefficients are identical; the code differs only in mnemonics used (vfmaq_f32 vs vmlaq_f32). They are both fed the same input. Should I be wrong about the polynomial being the single point where the arithmetic is not "exact"?

[marcusmueller]

Asking for @Ka-zam 's input on this, because I think he's most competent and nice!