-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std: Add arch
and simd
modules
#48513
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
#![feature(unboxed_closures)] | ||
#![feature(untagged_unions)] | ||
#![feature(unwind_attributes)] | ||
#![feature(doc_spotlight)] | ||
#![feature(rustc_const_unstable)] | ||
#![feature(iterator_repeat_with)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nit, but shouldn't moving these three around into a different spot be in a separate commit?
One minor nit, which I don't feel particularly strongly about, and otherwise this LGTM. |
☔ The latest upstream changes (presumably #48531) made this pull request unmergeable. Please resolve the merge conflicts. |
cc @rust-lang/libs, @BurntSushi, @gnzlbg |
Is the plan to always be importing stdsimd, or is this just temporary and it'll get inlined into this repo at some point? |
My thinking at least is that we'll forever be importing stdsimd as a submodule, that allows us to be way more creative with stdsimd's own CI and doesn't require us to hook it all up here as well |
src/libcore/lib.rs
Outdated
#[allow(missing_docs, missing_debug_implementations, dead_code)] | ||
#[unstable(feature = "stdsimd", issue = "0")] | ||
#[cfg(not(stage0))] // allow changes to how stdsimd works in stage0 | ||
mod coresimd; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Silly question: does this stage0 check preclude core/std from using anything from stdsimd?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would during stage0, yeah, but I'd imagine that most usage would largely be an optimization in which case tagging it as #[cfg(not(stage0))]
probably wouldn't be too bad.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that the alternative here is to manually add #[cfg(stage0)]
tags and such to stdsimd itself rather than blanket defining it for this module, and I figured that for the time being it's easiest to take this route which is only defining it in stage1+
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, good point. Yeah, the stage1 compiler just being a bit slower in some corner cases than it could be probably isn't a big deal.
6ee39fc
to
b5a585f
Compare
LGTM. Pulling in the |
@gnzlbg do you think the |
Nah, it's unstable. |
5fb66e2
to
4abbf01
Compare
FWIW I'd like to use |
@bors: r=JoshTriplett |
📌 Commit 4abbf01 has been approved by |
@scottmcm just be aware that the API will change a bit shortly and you'll be ok. |
@bors r- The
|
@bors: r=JoshTriplett |
📌 Commit 4d63f81 has been approved by |
@bors r- |
@Manishearth thanks! W/ an r- mind throwing in a link to the error logs as well? In this case it's important that it's wasm, for example, and doesn't otherwise happen by default. |
@Manishearth is there a way to view the result of all build bots? |
This commit imports the `stdsimd` crate into the standard library, creating an `arch` and `simd` module inside of both libcore and libstd. Both of these modules are **unstable** and will continue to be so until RFC 2335 is stabilized. As a brief recap, the modules are organized as so: * `arch` contains all current architectures with intrinsics, for example `std::arch::x86`, `std::arch::x86_64`, `std::arch::arm`, etc. These modules contain all of the intrinsics defined for the platform, like `_mm_set1_epi8`. * In the standard library, the `arch` module also exports a `is_target_feature_detected` macro which performs runtime detection to determine whether a target feature is available at runtime. * The `simd` module contains experimental versions of strongly-typed lane-aware SIMD primitives, to be fully fleshed out in a future RFC. The main purpose of this commit is to start pulling in all these intrinsics and such into the standard library on nightly and allow testing and such. This'll help allow users to easily kick the tires and see if intrinsics work as well as allow us to test out all the infrastructure for moving the intrinsics into the standard library.
@bors: r=JoshTriplett |
📌 Commit c72537f has been approved by |
std: Add `arch` and `simd` modules This commit imports the `stdsimd` crate into the standard library, creating an `arch` and `simd` module inside of both libcore and libstd. Both of these modules are **unstable** and will continue to be so until RFC 2335 is stabilized. As a brief recap, the modules are organized as so: * `arch` contains all current architectures with intrinsics, for example `std::arch::x86`, `std::arch::x86_64`, `std::arch::arm`, etc. These modules contain all of the intrinsics defined for the platform, like `_mm_set1_epi8`. * In the standard library, the `arch` module also exports a `is_target_feature_detected` macro which performs runtime detection to determine whether a target feature is available at runtime. * The `simd` module contains experimental versions of strongly-typed lane-aware SIMD primitives, to be fully fleshed out in a future RFC. The main purpose of this commit is to start pulling in all these intrinsics and such into the standard library on nightly and allow testing and such. This'll help allow users to easily kick the tires and see if intrinsics work as well as allow us to test out all the infrastructure for moving the intrinsics into the standard library.
This commit imports the
stdsimd
crate into the standard library,creating an
arch
andsimd
module inside of both libcore and libstd.Both of these modules are unstable and will continue to be so until
RFC 2335 is stabilized.
As a brief recap, the modules are organized as so:
arch
contains all current architectures with intrinsics, for examplestd::arch::x86
,std::arch::x86_64
,std::arch::arm
, etc. Thesemodules contain all of the intrinsics defined for the platform, like
_mm_set1_epi8
.arch
module also exports ais_target_feature_detected
macro which performs runtime detection todetermine whether a target feature is available at runtime.
simd
module contains experimental versions of strongly-typedlane-aware SIMD primitives, to be fully fleshed out in a future RFC.
The main purpose of this commit is to start pulling in all these
intrinsics and such into the standard library on nightly and allow
testing and such. This'll help allow users to easily kick the tires and
see if intrinsics work as well as allow us to test out all the
infrastructure for moving the intrinsics into the standard library.