-
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
Use volatile access instead of #[used]
for on_tls_callback
#121596
Conversation
rustbot has assigned @Mark-Simulacrum. Use r? to explicitly pick a reviewer |
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.
Looks good to me 👍. I whole-heartedly agree to the point about the compiler, I think we could do so much better in that regard... maybe something for #110897?
Maybe! I'll try to write up the issue on that thread when I have a moment. |
@bors r+ |
…llaumeGomez Rollup of 7 pull requests Successful merges: - rust-lang#119748 (Increase visibility of `join_path` and `split_paths`) - rust-lang#120820 (Enable CMPXCHG16B, SSE3, SAHF/LAHF and 128-bit Atomics (in nightly) in Windows x64) - rust-lang#121000 (pattern_analysis: rework how we hide empty private fields) - rust-lang#121376 (Skip unnecessary comparison with half-open range patterns) - rust-lang#121596 (Use volatile access instead of `#[used]` for `on_tls_callback`) - rust-lang#121669 (Count stashed errors again) - rust-lang#121783 (Emitter cleanups) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#121596 - ChrisDenton:tls, r=joboet Use volatile access instead of `#[used]` for `on_tls_callback` The first commit adds a volatile load of `p_thread_callback` when registering a dtor so that the compiler knows if the callback is used or not. I don't believe the added volatile instruction is otherwise significant in the context. In my testing using the volatile load allowed the compiler to correctly reason about whether `on_tls_callback` is used or not, allowing it to be omitted entirely in some cases. Admittedly it usually is used due to `Thread` but that can be avoided (e.g. in DLLs or with custom entry points that avoid the offending APIs). Ideally this would be something the compiler could help a bit more with so we didn't have to use tricks like `#[used]` or volatile. But alas. I also used this as an opportunity to clean up the `unused` lints which I don't think serve a purpose any more. The second commit removes the volatile load of `_tls_used` with `#cfg[target_thread_local]` because `#[thread_local]` already implies it. And if it ever didn't then `#[thread_local]` would be broken when there aren't any dtors.
The first commit adds a volatile load of
p_thread_callback
when registering a dtor so that the compiler knows if the callback is used or not. I don't believe the added volatile instruction is otherwise significant in the context. In my testing using the volatile load allowed the compiler to correctly reason about whetheron_tls_callback
is used or not, allowing it to be omitted entirely in some cases. Admittedly it usually is used due toThread
but that can be avoided (e.g. in DLLs or with custom entry points that avoid the offending APIs). Ideally this would be something the compiler could help a bit more with so we didn't have to use tricks like#[used]
or volatile. But alas.I also used this as an opportunity to clean up the
unused
lints which I don't think serve a purpose any more.The second commit removes the volatile load of
_tls_used
with#cfg[target_thread_local]
because#[thread_local]
already implies it. And if it ever didn't then#[thread_local]
would be broken when there aren't any dtors.