Using intrinsics instead of inline assembly in libm?

It seems that many architecture-specific implementations of libm functions use inline assembly instead of calling into intrinsics. This was apparently done in https://github.com/rust-lang/libm/pull/459 to "avoid recursion issues". I assume this means the compiler lowering a math intrinsic to a libm function, which refers back to a math intrinsic, which is lowered to a libm function... I'm worried that inline assembly could prevent a lot of optimizations. As far as I know, it's basically a black box as far as the compiler is concerned (and intentionally so). What is currently blocking the `libm` crate from using intrinsics? libm#459 referred to recursion issues with `cg_gcc` and unspecified "problems with `aarch64be`". I don't really have any more context than that. I suspect some of it might have to do with [the unstable `core_float_math` feature](https://github.com/rust-lang/rust/issues/137578), whose methods now seem to call into *compiler* intrinsics. Do those compiler intrinsics still have the potential to be lowered to libm calls? The "recursion" thing is a bit unfortunate, because it only applies when using the libm crate within Rust itself and allowing the compiler to emit libm calls. If you're using the libm crate for e.g. your `no_std` library, it doesn't apply, but you suffer a potential performance penalty anyway.