Conversation
|
r? @wesleywiser (rustbot has picked a reviewer for you, use r? to override) |
|
|
Cc @alexcrichton. |
This comment has been minimized.
This comment has been minimized.
|
This won't currently compile until rust-lang/stdarch#1494 is merged and updated, so for now this is waiting for the FCP first. |
68a0b5d to
b6847a7
Compare
This comment has been minimized.
This comment has been minimized.
|
Personally I'd say this is good to go (modulo CI of course), and it's something I forgot to do after the last CG meeting, thanks @daxpedda! For others this PR has relevant discussion namely some of the background laid you in this comment. The relaxed-simd proposal is a bit different where there's actual instructions to expose with new intrinsics, but this is following in the footsteps of the simd128 proposal and its intrinsics so AFAIK there's no new precedents set here or anything like that, mostly just following preexisting processes. |
|
@wesleywiser AFAIU this should probably not be marked as blocked. It's true that merging is blocked on rust-lang/stdarch#1494, but the FCP is required for rust-lang/stdarch#1494 to be merged in the first place. So I would like to request an FCP for stabilizing relaxed SIMD! |
|
This cover the @rfcbot fcp merge |
|
Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
|
Repeating what I posed on the tracking issue: I am confused by the spec here. Quoting from https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md:
Okay, so that's normal non-determinism then. Wasm already has that for NaNs when there are non-canonical inputs, which is strangely not acknowledged here (has that changed?), but sure, makes sense.
This describes something else! IIUC, it says that the operation, when executed twice in the same environment, must produce the same result. In other words, the non-determinism is fixed once at program startup, and the example givejn just above actually cannot happen within a single program/module execution. This is closer to what we usually call implementation-specific behavior than to full non-determinism. Can someone explain this seeming contradiction? |
|
To the best of my knowledge I believe that the contradiction is explained by the fact that the proposal has a long history and changed at one point. I believe your first quoted sentence is the original semantics when the proposal was first drafted and the second quote you listed is the desired semantics. For example this was the commit that introduced the first quote and it refers to an |
|
Okay, I've opened WebAssembly/relaxed-simd#153 to hopefully get clarification from the authors. For Rust, we should probably conservatively treat these as being non-deterministic at each operation. I don't think that should cause any issues? These are just LLVM intrinsics implemented via certain wasm instructions, right? |
No, we do nothing with the output (the part that might not be deterministic).
Indeed. |
|
☔ The latest upstream changes (presumably #117915) made this pull request unmergeable. Please resolve the merge conflicts. |
73fa528 to
f06dd33
Compare
This comment has been minimized.
This comment has been minimized.
f06dd33 to
d0e9a84
Compare
Thank you both, I've done just that! @wesleywiser this PR is ready to be merged again. |
d0e9a84 to
e0c838c
Compare
alexcrichton
left a comment
There was a problem hiding this comment.
I talked with @daxpedda about this and I believe I can approve PRs now so I'll try to take over this since it's wasm-specific. This looks good to me and while there's bits to sort out in relation to #128221 that seems ok to defer for a bit while that waits to land too. I've got one request here to expand a comment but otherwise I'm happy to send this back to bors
| // `+relaxed-simd` implies `+simd128` | ||
| if features.iter().any(|f| f == "+relaxed-simd") && !features.iter().any(|f| f == "+simd128") { | ||
| features.push("+simd128".into()); | ||
| } |
There was a problem hiding this comment.
Mind expanding this comment a bit? I think it'd be good to mention here:
- This code is wasm-specific
- Why this code is here and maybe a small snippet about how it relates to per-function features
- Maybe a quick mention of why this isn't generalized?
And then do you think it's worth adding a gate around this checking if the LLVM version is <= 19? That could link to the PR which changed this in upstream LLVM as well.
There was a problem hiding this comment.
Done! I hope its clear.
I also went ahead and renamed the whole system from "dependant" to "implicit", which is much more appropriate.
And then do you think it's worth adding a gate around this checking if the LLVM version is <= 19? That could link to the PR which changed this in upstream LLVM as well.
I will keep an eye on it and make a PR as soon as it actually lands.
4d0af88 to
61d95e2
Compare
|
@bors: r+ |
…crichton Stabilize Wasm relaxed SIMD This PR stabilizes [Wasm relaxed SIMD](https://github.com/WebAssembly/relaxed-simd) which has already reached [phase 4](https://github.com/WebAssembly/proposals/tree/04fa8c810e1dc99ab399e41052a6e427ee988180?tab=readme-ov-file#phase-4---standardize-the-feature-wg). Tracking issue: rust-lang#111196 Implementation PR: rust-lang/stdarch#1393 Documentation: rust-lang/reference#1421 Stdarch: rust-lang/stdarch#1494 Closes rust-lang#111196.
Rollup of 7 pull requests Successful merges: - rust-lang#117468 (Stabilize Wasm relaxed SIMD) - rust-lang#123813 (Add `REDUNDANT_IMPORTS` lint for new redundant import detection) - rust-lang#127060 (Migrate `symbol-visibility` `run-make` test to rmake) - rust-lang#127159 (match lowering: Hide `Candidate` from outside the lowering algorithm) - rust-lang#128296 (Update target-spec metadata for loongarch64 targets) - rust-lang#128416 (android: Remove libstd hacks for unsupported Android APIs) - rust-lang#128431 (Add myself as VxWorks target maintainer for reference) r? `@ghost` `@rustbot` modify labels: rollup
|
It looks like this may have caused the failure here #128454 (comment). Is it possible to update the @bors r- |
|
Sure! |
|
@Amanieu these errors look like AVX512 work related to the Stdarch update, would you know whats causing this or who to ping? |
|
It could also just be the RFL job having something wrong with target features, I brought it up on Zulip too. |
|
Stdarch update is happening in #128466, which this PR will be rebased on after its merged. |
|
#128466 (comment) merged so this should be ready for a rebase. |
|
@bors: r+ |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (9179d9b): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 7.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 757.802s -> 757.898s (0.01%) |
This PR stabilizes Wasm relaxed SIMD which has already reached phase 4.
Tracking issue: #111196
Implementation PR: rust-lang/stdarch#1393
Documentation: rust-lang/reference#1421
Stdarch: rust-lang/stdarch#1494
Closes #111196.