Not really - the initial implementation (without memcpy) resulted in an aligned move, and hence the crash. The memcpy implementation results in an SSE-based una

Not really - the initial implementation (without memcpy) resulted in an aligned move, and hence the crash. The memcpy implementation results in an SSE-based unaligned instruction that does the right thing, but is slower (in the specific case that the author cares about, ie cases where the loop will rarely trigger and will basically never go through more than three iterations) than not using SSE. There's no real way to hint to the compiler that this is the case, so the author chooses to disable the use of SSE in that function on architectures that support it - this way they can use memcpy() (for correctness) and still get the hoped for code generation.