Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @gnzlbg (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

Can you rebase this? The CI failures should be fixed now.

thread 'core_arch::x86::sse::assert__mm_loadu_si64_movups' panicked at 'failed to find instruction movups in the disassembly', crates/stdarch-test/src/lib.rs:157:9

What should I do? Should I change #[cfg_attr(test, assert_instr(movups))]?

movups is a 128-bit move. You want movq which is a 64-bit move.

Oh, it didn't use movq in the resulting code. It should be though.

error[E0635]: unknown feature const_transmute? Weird, is that removed from nightly?

const_transmute is now stable, you can remove the feature flag.

Thanks!

@Amanieu Can you please mark this function done in #40 first post checklist? Quite an interesting experience for me to work on this.

Done! However I am having second thoughts about exposing this function in SSE instead of SSE2. The Intel documentation seems to be incorrect since it says that this should use the MOVQ instruction but that instruction is only available in SSE2. Also both Clang and GCC only expose this intrinsic in the SSE2 header (emmintrin.h) rather than the SSE one (xmmintrin.h).

But even though Intel documentation is incorrect we need to follow them right?

Not really. IMO we should be following GCC and Clang which are the "standard" implementation for the compiler intrinsics. I believe even the Intel compiler puts _mm_loadu_si64 in emmintrin.h which implies it is a SSE2 intrinsic.