Skip to content
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.

Sign up for GitHub

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

Jump to bottom

core: Support variety of atomic widths in width-agnostic functions #106856

Merged
merged 2 commits into from
Jan 27, 2023
Merged

core: Support variety of atomic widths in width-agnostic functions #106856

merged 2 commits into from
Jan 27, 2023

Conversation

vadorovsky
Copy link
Contributor

@vadorovsky vadorovsky commented Jan 14, 2023 •
edited
Loading

Before this change, the following functions and macros were annotated with #[cfg(target_has_atomic = "8")] or
#[cfg(target_has_atomic_load_store = "8")]:

  • atomic_int
  • strongest_failure_ordering
  • atomic_swap
  • atomic_add
  • atomic_sub
  • atomic_compare_exchange
  • atomic_compare_exchange_weak
  • atomic_and
  • atomic_nand
  • atomic_or
  • atomic_xor
  • atomic_max
  • atomic_min
  • atomic_umax
  • atomic_umin

However, none of those functions and macros actually depend on 8-bit width and they are needed for all atomic widths (16-bit, 32-bit, 64-bit etc.). Some targets might not support 8-bit atomics (i.e. BPF, if we would enable atomic CAS for it).

This change fixes that by removing the "8" argument from annotations, which results in accepting the whole variety of widths.

Fixes #106845
Fixes #106795

Signed-off-by: Michal Rostecki vadorovsky@gmail.com

@rustbot
Copy link
Collaborator

rustbot commented Jan 14, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @scottmcm (or someone else) soon.

Please see the contribution instructions for more information.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 14, 2023
@rustbot
Copy link
Collaborator

rustbot commented Jan 14, 2023

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@vadorovsky vadorovsky mentioned this pull request Jan 14, 2023
Merged
@vadorovsky
Copy link
Contributor Author

@alessandrod @tomerze

alessandrod
alessandrod reviewed Jan 17, 2023
View reviewed changes
Copy link
Contributor

@alessandrod alessandrod left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really my place to review this, just my 2 cents

library/core/src/sync/atomic.rs Outdated Show resolved Hide resolved
library/core/src/sync/atomic.rs Outdated Show resolved Hide resolved
@vadorovsky vadorovsky force-pushed the fix-atomic-annotations branch 2 times, most recently from ef104b3 to e00a9a8 Compare January 18, 2023 12:58
@vadorovsky
Copy link
Contributor Author

@bjorn3 ping. Does it look good for you now?

@bjorn3
Copy link
Member

bjorn3 commented Jan 20, 2023

LGTM. I will defer to @scottmcm for a final review as I'm not on the libs team.

vadorovsky added a commit to vadorovsky/book that referenced this pull request Jan 22, 2023
@vadorovsky
examples: Pin Rust nightly to 2023-01-10
bde29f6 
We need to wait for the following fixes in Rust nightly to be able to
use the newest one:

* rust-lang/rust#106796
* rust-lang/rust#106856

Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
@vadorovsky vadorovsky mentioned this pull request Jan 22, 2023
Merged
vadorovsky added a commit to vadorovsky/book that referenced this pull request Jan 22, 2023
@vadorovsky
examples: Pin Rust nightly to 2023-01-10
cd09cf3 
We need to wait for the following fixes in Rust nightly to be able to
use the newest one:

* rust-lang/rust#106796
* rust-lang/rust#106856

Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
vadorovsky added a commit to vadorovsky/book that referenced this pull request Jan 22, 2023
@vadorovsky
examples: Pin Rust nightly to 2023-01-10
fbf7bc6 
We need to wait for the following fixes in Rust nightly to be able to
use the newest one:

* rust-lang/rust#106796
* rust-lang/rust#106856

Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
vadorovsky added a commit to vadorovsky/book that referenced this pull request Jan 22, 2023
@vadorovsky
examples: Pin Rust nightly to 2023-01-10
9d69141 
We need to wait for the following fixes in Rust nightly to be able to
use the newest one:

* rust-lang/rust#106796
* rust-lang/rust#106856

Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
@vadorovsky
Copy link
Contributor Author

@scottmcm ping

Sorry for rushing, but it's quite urgent PR, we are trying to unblock BPF builds in Nightly.

@bjorn3 bjorn3 mentioned this pull request Jan 23, 2023
Closed
@vadorovsky
Add target_has_atomic* symbols if any atomic width is supported
1cd7dbf 
Atomic operations for different widths (8-bit, 16-bit, 32-bit etc.) are
guarded by `target_has_atomic = "value"` symbol (i.e. `target_has_atomic
= "8"`) (and the other derivatives), but before this change, there was
no width-agnostic symbol indicating a general availability of atomic
operations.

This change introduces:

* `target_has_atomic_load_store` symbol when atomics for any integer
  width are supported by the target.
* `target_has_atomic` symbol when also CAS is supported.

Fixes rust-lang#106845

Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
@vadorovsky
core: Support variety of atomic widths in width-agnostic functions
474ea87 
Before this change, the following functions and macros were annotated
with `#[cfg(target_has_atomic = "8")]` or
`#[cfg(target_has_atomic_load_store = "8")]`:

* `atomic_int`
* `strongest_failure_ordering`
* `atomic_swap`
* `atomic_add`
* `atomic_sub`
* `atomic_compare_exchange`
* `atomic_compare_exchange_weak`
* `atomic_and`
* `atomic_nand`
* `atomic_or`
* `atomic_xor`
* `atomic_max`
* `atomic_min`
* `atomic_umax`
* `atomic_umin`

However, none of those functions and macros actually depend on 8-bit
width and they are needed for all atomic widths (16-bit, 32-bit, 64-bit
etc.). Some targets might not support 8-bit atomics (i.e. BPF, if we
would enable atomic CAS for it).

This change fixes that by removing the `"8"` argument from annotations,
which results in accepting the whole variety of widths.

Fixes rust-lang#106845
Fixes rust-lang#106795

Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
@joshtriplett
Copy link
Member

This seems fine to me for nightly.

I think this would probably be fine to stabilize, but I'd want to give some more detailed thought to the case of unsupported sizes on a given target. I think that works correctly, and the way @alessandrod explained it to me on Zulip made sense, but I'd want to doublecheck before stabilizing.

But for nightly:

@bors r+

@bors
Copy link
Contributor

bors commented Jan 26, 2023

📌 Commit 474ea87 has been approved by joshtriplett

It is now in the queue for this repository.

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 26, 2023
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 26, 2023
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jan 27, 2023
@JohnTitor
Rollup merge of rust-lang#106856 - vadorovsky:fix-atomic-annotations,…
a4e6bb0 
… r=joshtriplett

core: Support variety of atomic widths in width-agnostic functions

Before this change, the following functions and macros were annotated with `#[cfg(target_has_atomic = "8")]` or
`#[cfg(target_has_atomic_load_store = "8")]`:

* `atomic_int`
* `strongest_failure_ordering`
* `atomic_swap`
* `atomic_add`
* `atomic_sub`
* `atomic_compare_exchange`
* `atomic_compare_exchange_weak`
* `atomic_and`
* `atomic_nand`
* `atomic_or`
* `atomic_xor`
* `atomic_max`
* `atomic_min`
* `atomic_umax`
* `atomic_umin`

However, none of those functions and macros actually depend on 8-bit width and they are needed for all atomic widths (16-bit, 32-bit, 64-bit etc.). Some targets might not support 8-bit atomics (i.e. BPF, if we would enable atomic CAS for it).

This change fixes that by removing the `"8"` argument from annotations, which results in accepting the whole variety of widths.

Fixes rust-lang#106845
Fixes rust-lang#106795

Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
@JohnTitor JohnTitor mentioned this pull request Jan 27, 2023
Closed
@JohnTitor JohnTitor mentioned this pull request Jan 27, 2023
Merged
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 27, 2023
@bors
Auto merge of rust-lang#107343 - JohnTitor:rollup-s6l94aj, r=JohnTitor
18890f0 
Rollup of 8 pull requests

Successful merges:

 - rust-lang#105784 (update stdarch)
 - rust-lang#106856 (core: Support variety of atomic widths in width-agnostic functions)
 - rust-lang#107171 (rustc_metadata: Fix `encode_attrs`)
 - rust-lang#107242 (rustdoc: make item links consistently use `title="{shortty} {path}"`)
 - rust-lang#107279 (Use new solver during selection)
 - rust-lang#107284 (rustdoc: use smarter encoding for playground URL)
 - rust-lang#107325 (rustdoc: Stop using `HirId`s)
 - rust-lang#107336 (rustdoc: remove mostly-unused CSS classes `import-item` and `module-item`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit bf321ec into rust-lang:master Jan 27, 2023
@rustbot rustbot added this to the 1.69.0 milestone Jan 27, 2023
@taiki-e taiki-e mentioned this pull request Feb 18, 2023
Closed
@vadorovsky vadorovsky mentioned this pull request Mar 2, 2023
Closed
@ascjones ascjones mentioned this pull request Mar 14, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@bjorn3 bjorn3 bjorn3 left review comments

@alessandrod alessandrod alessandrod left review comments

Assignees

@scottmcm scottmcm

Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.69.0
7 participants
@vadorovsky @rustbot @bjorn3 @joshtriplett @bors @alessandrod @scottmcm