-
Notifications
You must be signed in to change notification settings - Fork 13.4k
atomic_load intrinsic: use const generic parameter for ordering #141507
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
Conversation
r? @fee1-dead rustbot has assigned @fee1-dead. Use |
Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr The Miri subtree was changed cc @rust-lang/miri Some changes occurred to the CTFE machinery Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri Some changes occurred in compiler/rustc_codegen_ssa Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 |
23b2539
to
4c7129b
Compare
This comment has been minimized.
This comment has been minimized.
Correct. Wasm and by extension Cranelift only have SeqCst atomics. |
8dbc7a6
to
0cd5bdb
Compare
This comment has been minimized.
This comment has been minimized.
0cd5bdb
to
dc1bd79
Compare
This comment has been minimized.
This comment has been minimized.
dc1bd79
to
a9e3996
Compare
I think that anything the compiler lets you do with solely |
Even though this on the whole LGTM, I'm not really familiar with the backend, so.. r? bjorn3 |
a9e3996
to
cf77933
Compare
This comment has been minimized.
This comment has been minimized.
cf77933
to
27cd3eb
Compare
The first two commits LGTM, so if you want to open a separate PR, they can be r+'ed immediately. |
intrinsics, ScalarInt: minor cleanup Taken out of rust-lang#141507 while we resolve technical disagreements in that PR. r? `@bjorn3`
intrinsics, ScalarInt: minor cleanup Taken out of rust-lang#141507 while we resolve technical disagreements in that PR. r? ``@bjorn3``
LGTM, but there will be a minor conflict with #141404 which is currently in the queue. r=me once it merges and the conflict is fixed. |
28cacd2
to
d2a9cb0
Compare
d2a9cb0
to
a387c86
Compare
@bors r=bjorn3 |
Rollup of 8 pull requests Successful merges: - #133823 (Use `cfg_attr_trace` in AST with a placeholder attribute for accurate suggestion) - #141004 (Report text_direction_codepoint_in_literal when parsing) - #141407 (Refactor the two-phase check for impls and impl items) - #141430 (remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`) - #141507 (atomic_load intrinsic: use const generic parameter for ordering) - #141538 (implement `va_arg` for x86_64 systemv) - #141669 (float: Replace some approximate assertions with exact) - #141747 (rustdoc: display doc(cfg(false)) properly) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #141507 - RalfJung:atomic-intrinsics, r=bjorn3 atomic_load intrinsic: use const generic parameter for ordering We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that! This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics. The first two commits are preparation and could be a separate PR if you prefer. `@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer... `@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
intrinsics, ScalarInt: minor cleanup Taken out of rust-lang#141507 while we resolve technical disagreements in that PR. r? ``@bjorn3``
Rollup of 8 pull requests Successful merges: - rust-lang/rust#133823 (Use `cfg_attr_trace` in AST with a placeholder attribute for accurate suggestion) - rust-lang/rust#141004 (Report text_direction_codepoint_in_literal when parsing) - rust-lang/rust#141407 (Refactor the two-phase check for impls and impl items) - rust-lang/rust#141430 (remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`) - rust-lang/rust#141507 (atomic_load intrinsic: use const generic parameter for ordering) - rust-lang/rust#141538 (implement `va_arg` for x86_64 systemv) - rust-lang/rust#141669 (float: Replace some approximate assertions with exact) - rust-lang/rust#141747 (rustdoc: display doc(cfg(false)) properly) r? `@ghost` `@rustbot` modify labels: rollup
Relevant upstream PRs: - rust-lang/rust#141507 (identified by @tautschnig): replaces the atomic_load intrinstics (`atomic_load_seqcst`, `atomic_load_acquire`, and `atomic_load_relaxed`) by a new `atomic_load` intrinsic that is generic in the atomic ordering. Update the Kani code and tests accordingly. - rust-lang/rust#137574: Moved the `num` module from `std/src/num.rs` to `std/src/num/mod.rs` which required updating the corresponding path in the `script-based-pre/verify_std_cmd` test. Resolves #4120 ### Call-outs: - Instead of replacing the `String` parameter of Kani's `AtomicLoad` enum variant by `AtomicOrdering`, I opted to remove the parameter altogether since Kani doesn't do anything with it at the moment. We can easily add a parameter to that enum variant in the future if Kani needs it. - The upstream change to `atomic_load` is expected to be followed by similar changes to all atomic intrinsics. By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
atomic_load intrinsic: use const generic parameter for ordering We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that! This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics. The first two commits are preparation and could be a separate PR if you prefer. `@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer... `@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
In rust-lang/rust#141507, the `atomic_load_{ordering}` intrinsics were removed and replaced with a single `atomic_load` intrinsic. This commit moves the portable-atomic crate to that new intrinsic.
In rust-lang/rust#141507, the `atomic_load_{ordering}` intrinsics were gated behind the `bootstrap` config and replaced with a single `atomic_load` intrinsic. This commit moves the portable-atomic crate to that new intrinsic.
…r=bjorn3 Atomic intrinsics : use const generic ordering, part 2 This completes what got started in rust-lang#141507 by using a const generic for the ordering for all intrinsics. It is based on that PR; only the last commit is new. Blocked on: - rust-lang#141507 - rust-lang#141687 - rust-lang/stdarch#1811 - rust-lang#141964 r? `@bjorn3`
…r=bjorn3 Atomic intrinsics : use const generic ordering, part 2 This completes what got started in rust-lang#141507 by using a const generic for the ordering for all intrinsics. It is based on that PR; only the last commit is new. Blocked on: - rust-lang#141507 - rust-lang#141687 - rust-lang/stdarch#1811 - rust-lang#141964 r? ``@bjorn3``
…r=bjorn3 Atomic intrinsics : use const generic ordering, part 2 This completes what got started in rust-lang#141507 by using a const generic for the ordering for all intrinsics. It is based on that PR; only the last commit is new. Blocked on: - rust-lang#141507 - rust-lang#141687 - rust-lang/stdarch#1811 - rust-lang#141964 r? ```@bjorn3```
Atomic intrinsics : use const generic ordering, part 2 This completes what got started in #141507 by using a const generic for the ordering for all intrinsics. It is based on that PR; only the last commit is new. Blocked on: - #141507 - #141687 - rust-lang/stdarch#1811 - #141964 r? `@bjorn3`
Atomic intrinsics : use const generic ordering, part 2 This completes what got started in rust-lang/rust#141507 by using a const generic for the ordering for all intrinsics. It is based on that PR; only the last commit is new. Blocked on: - rust-lang/rust#141507 - rust-lang/rust#141687 - rust-lang/stdarch#1811 - rust-lang/rust#141964 r? `@bjorn3`
We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!
This PR only converts
load
, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.The first two commits are preparation and could be a separate PR if you prefer.
@BoxyUwU -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...
@bjorn3 it seems like the cranelift backend entirely ignores the ordering?