Add Neon implementation of std::swap_ranges

[hazzlim]

Add an implementation of std::swap_ranges using Neon intrinsics.

[hazzlim]

@microsoft-github-policy-service agree company="Arm"

[hazzlim]

Hopefully I’ve done something reasonable here - please let me know if you would prefer a different approach when adding new implementations to vector_algorithms.cpp

The performance numbers are below - looks good apart from the case of size(1), which I think is due to the added overhead of the function call and the conditional checks now std::swap_ranges is not being inlined into the benchmark.

	MSVC Speedup
std_swap_ranges<uint8_t, highly_aligned_allocator>/1	0.5x
std_swap_ranges<uint8_t, highly_aligned_allocator>/5	0.9x
std_swap_ranges<uint8_t, highly_aligned_allocator>/15	1.9x
std_swap_ranges<uint8_t, highly_aligned_allocator>/26	4.1x
std_swap_ranges<uint8_t, highly_aligned_allocator>/38	4.8x
std_swap_ranges<uint8_t, highly_aligned_allocator>/60	7.3x
std_swap_ranges<uint8_t, highly_aligned_allocator>/125	12.3x
std_swap_ranges<uint8_t, highly_aligned_allocator>/800	21.9x
std_swap_ranges<uint8_t, highly_aligned_allocator>/3000	22.4x
std_swap_ranges<uint8_t, highly_aligned_allocator>/9000	22.5x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/1	0.5x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/5	1x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/15	1.9x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/26	3.9x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/38	4.9x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/60	7.5x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/125	11.8x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/800	14.6x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/3000	15.1x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/9000	14.7x
	clang-cl Speedup
std_swap_ranges<uint8_t, highly_aligned_allocator>/1	0.6x
std_swap_ranges<uint8_t, highly_aligned_allocator>/5	1.1x
std_swap_ranges<uint8_t, highly_aligned_allocator>/15	1.5x
std_swap_ranges<uint8_t, highly_aligned_allocator>/26	1.4x
std_swap_ranges<uint8_t, highly_aligned_allocator>/38	1.4x
std_swap_ranges<uint8_t, highly_aligned_allocator>/60	1.5x
std_swap_ranges<uint8_t, highly_aligned_allocator>/125	1.5x
std_swap_ranges<uint8_t, highly_aligned_allocator>/800	1x
std_swap_ranges<uint8_t, highly_aligned_allocator>/3000	1x
std_swap_ranges<uint8_t, highly_aligned_allocator>/9000	1x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/1	0.6x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/5	1.2x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/15	1.5x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/26	1x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/38	1.2x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/60	1.4x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/125	1.4x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/800	1x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/3000	1x
std_swap_ranges<uint8_t, not_highly_aligned_allocator>/9000	1.1x

[StephanTLavavej]

Just confirming, no change requested: This is accessing _First1 and _First2 as uint32_t*, but they aren't necessarily 4-byte aligned. Is this cromulent?

We have test coverage for this scenario so I think we're good:

STL/tests/std/tests/VSO_0000000_vector_algorithms/test.cpp

Lines 1119 to 1123 in 1118f37

	// also test unaligned input
	const auto endOffset = min(static_cast<ptrdiff_t>(dataCount), attempts + 1);
	assert(
	right.begin() + (endOffset - 1) == swap_ranges(left.begin() + 1, left.begin() + endOffset, right.begin()));
	last_known_good_swap_ranges(leftCopy.begin() + 1, leftCopy.begin() + endOffset, rightCopy.begin());

[hazzlim]

I can see this was discussed on the discord also, but for the record here - yes this is fine as the LD1 lane instructions this will produce allow unaligned loads.

[StephanTLavavej]

Thanks @hazzlim, this is awesome! 😻 I pushed some commits, can you rerun your benchmark measurements? We finally have ARM64 runtime testing in PR checks, but I won't be able to gather perf measurements myself until Feb 2026-ish. The changes to override /Os for ARM64, and to eliminate unnecessary loops, should improve performance but perhaps by an unobservable amount.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[hazzlim]

Thanks @hazzlim, this is awesome! 😻 I pushed some commits, can you rerun your benchmark measurements? We finally have ARM64 runtime testing in PR checks, but I won't be able to gather perf measurements myself until Feb 2026-ish. The changes to override /Os for ARM64, and to eliminate unnecessary loops, should improve performance but perhaps by an unobservable amount.

Nice, thanks for doing this! Not sure how I missed that we could remove the loops for len < 64, nice one 😺

I will re-run the perf and report, it may well be unobservable but I think it should also improve the LDP generation so that's a win :)