You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment there's the llvm_intrinsically_optimized! macro which, when using the unstable flag, will call an unstable LLVM intrinsic.
However, there's some opportunities for using intrinsics (edit: hardware intrinsics) in stable, and even in core, if we wanted to reach for SSE / SSE2 / etc when available (compile time detected).
Of course this should probably be behind its own feature flag, but I think it would be a reasonable progression to develop in this direction of using stable hardware intrinsics when possible.
The text was updated successfully, but these errors were encountered:
I think it's fine to improve on the implementations here at any time basically. These intrinsics may not be used in libstd at this time on all platforms, but having optimized implementations would certainly help, and they'll all be well tested anyway
At the moment there's the
llvm_intrinsically_optimized!
macro which, when using the unstable flag, will call an unstable LLVM intrinsic.However, there's some opportunities for using intrinsics (edit: hardware intrinsics) in stable, and even in core, if we wanted to reach for SSE / SSE2 / etc when available (compile time detected).
For example,
libm
defines sqrt with a full software implementation, but if people call it instd
they get either (in debug) thesqrtss
instruction with some indirection in between or (in release) thesqrtss
instruction without any indirection. Based on this, I think it would be fine to havelibm
also just use thesqrtss
instruction when available.Of course this should probably be behind its own feature flag, but I think it would be a reasonable progression to develop in this direction of using stable hardware intrinsics when possible.
The text was updated successfully, but these errors were encountered: