[thesyncim]

The change is the first commit; the second only regenerates the goldens and bench/ops_simd.go.

This changes the shape of the generated element-wise loop. Across bench/ it's about 2.75x faster than what master generates on an M4 Max, and 27-43% faster on the amd64 runners. Most of the gain comes from getting the compiler to drop every check inside the loop.

Right now each iteration is a LoadPart/StorePart, and each call works out how many elements are left. arm64 has no masked loads, so that becomes a cascade of compares and register moves per vector, about 50 instructions per 4 lanes in AccumRowInt32s. On top of that, the bounds checks for slicing each operand at _i stay in the loop on every target.

The new loop:

_w1 := dst[:len(dst):len(dst)]
_count := len(_w1)
_w2, _w3 := a[:_count:_count], b[:_count:_count]
_i, _lanes := 0, simd.BroadcastFloat32s(0).Len()
for ; _i <= _count-4*_lanes; _i += 4 * _lanes {
	_c1, _c2, _c3 := _w1[_i:][:4*_lanes], _w2[_i:][:4*_lanes], _w3[_i:][:4*_lanes]
	simd.LoadFloat32s(_c2).Add(simd.LoadFloat32s(_c3)).Store(_c1)
	// ...the same at [_lanes:], [2*_lanes:] and [3*_lanes:]
}
for ; _i <= _count-_lanes; _i += _lanes {
	// one vector
}
for _i < _count {
	// one partial vector, as before
}

Every operand is cut to its window up front. Each window's length and capacity are _count, and _count is a len(), so the compiler knows it isn't negative. Given _i <= _count-k*_lanes, prove can then show that every slice taken inside the loop is in bounds, and the main loop comes down to the loads, the operation, the stores, the increment and the branch. Each of those details matters. I measured the alternatives on arm64, and each costs 30-50%: writing _i+_lanes <= limit, slicing the original operands at _i+off, taking the count from an expression like len(dst)-1, or using two-index windows.

The unrolled body runs four copies one after another, each with all the statements in order. So the chunks happen in the same order as they would one vector at a time, and a read ahead of a stored slice still happens before that copy's stores. Reductions keep their own loop but use the same condition. Integer reductions now also get the four accumulators that float reductions already had: an integer vector add takes two cycles on arm64, and SumInt32s gets 3x faster. Integer folds wrap, so regrouping them gives exactly the same result.

Since partial loads now only ever see less than a full vector, the emulated Load*Part from golang/go#82001 (which returns len(s)) gives the right count, and GODEBUG=simd=0 builds produce the scalar result. I updated BUGS.md for that.

Numbers are from bench/, best of 6 interleaved runs, in ns/op on an M4 Max:

n=4096	master	this PR	clang -O3
AddFloat32s	851	326	190
AccumRowInt32s	1535	316	196
DiffInt32s	1740	325	158
ClampInt32s	1056	286	138
SumInt32s	524	168	115
ReLUFloat32s	755	353	503

The geomean against master is 0.48x at n=64, 0.31x at 4096 and 0.32x at 1M. On the GitHub runners, measured together with #18, it's -32% on an EPYC 9V45 (Zen 5, AVX-512) and -43% on an EPYC 7763 (Zen 3, AVX2). The only kernel slower than master there is FillUint8s/64 (+10%): that's a single 64-lane store, where the setup now costs more than the store does.

For context, I also compiled the same loops as C with clang -O3 -mcpu=apple-m4. Master's code took 4.4x as long as clang's; with this it's 1.58x (1.50x at 4096, 1.16x at 1M). Most of what remains is on the compiler side: Go doesn't pair adjacent 128-bit loads and stores into ldp/stp, and each inlined simd call leaves NOPs in the loop.

On tests: the goldens are regenerated. A new loop_shape.txt runs sizes 0-300, and byte loops past 4×64, through every part of the loop for several body shapes, and both builds must print the same checksums. The bench/ fuzzers ran for 15-30s each and TSVC TestGolden passes through toolexec.

It needs #16, which keeps the new names (_count, _w1, ...) from capturing the function's own, and mauri870#2: the windows are cut from the loop's bounds, and mauri870#2 rejects a constant bound or offset that puts an index below zero instead of rewriting it.

I started on this because the generated code was slower than scalar for a lot of loops on arm64 when I tried loopvec on goav1.