[v-code01]

Follow-up to #6250, which it also corrects for non-unit strides (below). With OpenMP on Apple M4, the other level-1 routines that thread above n = 10000 have the same problem axpy had: libomp parks idle threads on Apple Silicon (KMP_BLOCKTIME defaults to 0 there), and above n = 10000 every call wakes the whole team, which costs about 44 us with the default 14 threads on an M4 Pro, whatever the size of the call. That covers zaxpy (interface) and the arm64 asum, sum, copy, dot, zdot, iamax and izamax kernels that VORTEXM4 uses.

This moves the check from axpy.c into common_thread.h as apple_omp_level1_threads(bytes, unit_stride, nthreads), where bytes is the memory the call reads and writes, and calls it right after each of these routines picks its thread count. A unit-stride call stays on one thread while it moves less than (nthreads - 1) x 384 KB. Measured against one thread, the crossover with the default team is between about 5.2 and 6.5 MB of traffic for all of these routines (asum, sum and iamax read one vector, dot reads two, copy reads one and writes one, axpy reads two and writes one), so one budget per woken thread fits all of them. For axpy, which moves three vectors, it is exactly the 128 KB per vector of #6250, so unit-stride axpy behaves as before.

Calls with any other stride keep the whole team. Their kernels handle one element per iteration and are 1.5 to 15 times slower per element than the unit-stride ones (about 15 for sasum), so one thread loses to the team well inside the byte budget. #6250 got this wrong for real axpy: with this change, saxpy with n = 300000 and stride 2 goes from 151 us in develop to 61 us, and daxpy with n = 200000 and stride 4 from 113 us to 57 us, because strided axpy uses the team again, as before #6250.

As before, it applies only to OpenMP builds for VORTEXM4 and to DYNAMIC_ARCH OpenMP builds running on vortexm4; pthreads builds and other targets behave as before. With OMP_WAIT_POLICY=active libomp keeps the team spinning and waking it is cheap, so calls near the budget are faster with the team (caxpy at n = 200000: 14 us with the team, 40.5 us on one thread), while smaller ones still gain; #6250 has the same trade-off. In Makefile builds VORTEXM4's scsum uses csum.S, so the csum_thunderx2t99.c change only takes effect in CMake builds.

Measured on an M4 Pro (10 performance and 4 efficiency cores), macOS 15.7.9, develop built with Homebrew LLVM 23.1.5 as DYNAMIC_ARCH=1 USE_OPENMP=1 NUM_THREADS=56 (without LAPACK). Each cell is the mean call time over 100 ms of back-to-back calls, starting 150 ms into the process, as the median over 7 rounds that run all cells in a new random order; the ratio is the median before over the median after, with a 95% bootstrap interval over rounds. Default thread count (14); cells marked (same) use the same thread count in both builds:

routine	n = 12000 before, us	after, us	ratio	n = 200000 before, us	after, us	ratio	n = 1000000 ratio
caxpy	44.4	2.45	18.2 [17.8, 18.6]	49.5	40.6	1.22 [1.19, 1.24]	0.99 [0.98, 1.01] (same)
zaxpy	44.8	4.55	9.8 [9.8, 9.9]	53.1	53.2	1.00 [0.98, 1.03] (same)	1.02 [0.95, 1.10] (same)
sasum	43.8	0.42	104.8 [101.8, 106.3]	45.0	7.2	6.22 [6.11, 6.30]	1.35 [1.32, 1.38]
dasum	44.0	0.78	56.1 [55.9, 57.5]	46.6	14.3	3.25 [3.19, 3.28]	1.01 [1.00, 1.05] (same)
scasum	43.9	0.77	57.2 [56.5, 58.4]	46.6	14.3	3.26 [3.14, 3.29]	1.00 [0.99, 1.01] (same)
dzasum	44.3	1.70	26.1 [25.7, 26.6]	47.9	28.9	1.66 [1.65, 1.67]	1.01 [1.00, 1.02] (same)
ssum	44.0	0.35	126.4 [125.1, 127.3]	45.6	7.4	6.16 [6.03, 6.23]	1.33 [1.28, 1.34]
dsum	43.9	0.65	67.5 [66.8, 68.6]	46.2	14.7	3.15 [3.14, 3.17]	1.00 [0.98, 1.02] (same)
scopy	44.0	0.87	50.6 [48.1, 52.3]	46.3	13.1	3.52 [3.50, 3.60]	1.02 [0.99, 1.06] (same)
dcopy	44.2	1.56	28.4 [28.1, 28.7]	47.5	26.5	1.80 [1.79, 1.81]	0.98 [0.95, 1.03] (same)
sdot	44.3	0.70	63.6 [61.9, 64.7]	46.6	14.7	3.16 [3.09, 3.20]	1.00 [0.96, 1.04] (same)
ddot	44.6	1.72	25.9 [25.5, 26.2]	48.2	29.4	1.64 [1.59, 1.66]	0.99 [0.95, 0.99] (same)
isamax	44.1	0.44	101.3 [100.8, 102.4]	45.4	7.8	5.84 [5.65, 5.86]	1.27 [1.19, 1.29]
idamax	44.2	0.84	52.5 [52.3, 52.9]	46.8	15.5	3.02 [2.96, 3.05]	1.00 [0.98, 1.03] (same)

Over the full run (these 14 routines, n = 12000 to 2000000, and the default, 4 and 8 threads), all 122 cells where the thread count changes are faster, by 1.22 to 126 times; the other 130 cells use the same thread count in both builds and range from 0.91 to 1.09 across processes.

Results: copy, iamax, izamax and real axpy are bit for bit unchanged. The reductions (asum, sum, dot) and, with unit stride, complex axpy already depend on how the vector is split between threads: in develop, caxpy at n = 30000 gives slightly different values for the last elements of each thread's part with 14 threads than with one (up to 4.5e-6 relative per real or imaginary part, about 1e-7 relative to |y|). Where this change moves a call to one thread, the result is now exactly the one-thread result of develop; elsewhere it is unchanged. Checked for s, d, c and z variants, sizes on both sides of the threshold for teams 2 to 14, unit, positive, negative and zero strides, and 1, 2, 4, 8, 12 and 14 threads, OMP_ADAPTIVE=1, openblas_set_num_threads and a nested parallel region; the thread counts actually used match the rule in every case.