w.r.t. to SIMD, there are two prongs to it: * Platform dependent functions that match an upstream vendor's API. (Think __m128i and friends.) * Platform indepe

w.r.t. to SIMD, there are two prongs to it: * Platform dependent functions that match an upstream vendor's API. (Think __m128i and friends.) * Platform independent APIs that provide portable vector APIs. The former is necessary because the latter cannot ever hope to cover all use cases supported by CPUs. The latter is necessary because it can hit many use cases, and finding the optimal implementation for every operation for every permutation of platform (and every permutation of CPU feature on each platform) is a non-trivial task. So yeah, that is indeed a ton of work. However, LLVM does a lot of the heavy lifting for us, particularly with respect to the implementation of the portable API. "All" we have to do is define an API we're willing to stabilize in `std`. (Which is no easy task.) I'm less in touch with the inline ASM feature, but like most things, I expect it is much more complex than you're suggesting. You can read more about it on the tracking issue for inline ASM[1]. Remember, if we're stabilizing something, then we need to make sure it continues to work. If LLVM's doesn't uphold that guarantee, that we must necessarily provide our own interface that is stable. "Just expose LLVM's internals" is not really an acceptable answer, and it was in fact a large part of the SIMD effort (building APIs we can stabilize on top of what LLVM supports). I'd also like to note that the stabilization of the former piece above (platform dependent vendor intrinsics) eats into many of the use cases for inline ASM. Not all of course, but many. :-) [1] - https://github.com/rust-lang/rust/issues/29722 https://github.com/rust-lang/rust/issues/29722