Improving std::simd::swizzle_dyn

Summary

Fearless SIMD recently received a pull request that started like this:Swizzles are a whole can of worm and I do not intend to figure out how we should implement this generically right now. 😄The pull request author only wanted to convert RGBA image layouts, e.g. RGBA <-> BGRA, so we solved the immediate need by implementing a simpler version that shuffles bytes within 128-bit blocks. That way we can trivially support this operation even on 512-bit vectors on 128-bit hardware, and 512-bit hardware still gets to utilize its full potential with native instructions.But that made me wonder: how does std::simd implement arbitrary swizzles that aren't confined to 128-bit blocks? Turns out the answer is: poorly.Over the course of this article we're going to fix some of that.What is a swizzle?A swizzle, or a shuffle, rearranges elements within an array.For example, if I have the input array [A,D,F,I,M,R,S,T] and apply the swizzle mask [2,0,6,7,6,3,4,1], I get [F,A,S,T,S,I,M,D].The dyn part indicates that the swizzle mask is dynamic (not hardcoded), so you could supply the swizzle mask [6,4,0,5,7,0,6,6] at runtime to get a different word.This example uses only 8 bytes, or 64 bits. In practice hardware implements shuffles on vector sizes from 128 to 512 bits, and so does std::simd.Understanding the implementationOn a high level, the current implementation of std::simd::swizzle_dyn is very simple: use the native hardware operation if available, otherwise give up and move bytes one by one.Even when hardware shuffles for a given size are available, swizzle_dyn doesn't always map to the hardware cleanly. It promises that the values for out-of-bounds indices will be set to 0, while x86 hardware shuffle just lets them wrap, so swizzle_dyn has to do extra work to uphold this guarantee.Wait a minute... what is this warning in its documentation?Note that the current implementation is selected during build-time of the standard library, so cargo build -Zbuild-std may be necessary to unloc...