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.

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 #[inline(always)] on trivial UnsafeCell methods #83858

Merged
merged 1 commit into from
Apr 5, 2021

Conversation

joshtriplett
Copy link
Member

UnsafeCell is the standard building block for shared mutable data
structures. UnsafeCell should add zero overhead compared to using raw
pointers directly.

Some reports suggest that debug builds, or even builds at opt-level 1,
may not always be inlining its methods. Mark the methods as
#[inline(always)], since once inlined the methods should result in no
actual code other than field accesses.

UnsafeCell is the standard building block for shared mutable data
structures. UnsafeCell should add zero overhead compared to using raw
pointers directly.

Some reports suggest that debug builds, or even builds at opt-level 1,
may not always be inlining its methods. Mark the methods as
`#[inline(always)]`, since once inlined the methods should result in no
actual code other than field accesses.
@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 4, 2021
@joshtriplett
Copy link
Member Author

joshtriplett commented Apr 4, 2021

I'd expect this to be performance-neutral for optimized code (including rustc), but let's make sure:

@bors try @rust-timer queue

@bors
Copy link
Contributor

bors commented Apr 4, 2021

⌛ Trying commit 37498a1 with merge 22cffcc1b41f3fa0b95ea1add2096cfa12b43681...

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Apr 4, 2021
@Mark-Simulacrum
Copy link
Member

Do you have evidence to suggest this actually fixes the inlining problems? It seems odd that LLVM is not inlining such trivial functions (they're generic so should be available for that), so maybe a deeper investigation is worthwhile, though it doesn't necessarily need to block this PR.

Cc @rust-lang/lang

@Mark-Simulacrum
Copy link
Member

Er that was meant to be @rust-lang/wg-llvm , sorry lang team :)

@nikic
Copy link
Contributor

nikic commented Apr 4, 2021

Both O0 and O1 only inline always_inline functions, so that's in line with expectations. As far as rust is concerned, O1 is essentially useless.

@bors
Copy link
Contributor

bors commented Apr 4, 2021

☀️ Try build successful - checks-actions
Build commit: 22cffcc1b41f3fa0b95ea1add2096cfa12b43681 (22cffcc1b41f3fa0b95ea1add2096cfa12b43681)

@rust-timer
Copy link
Collaborator

Queued 22cffcc1b41f3fa0b95ea1add2096cfa12b43681 with parent 5b0ab79, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (22cffcc1b41f3fa0b95ea1add2096cfa12b43681): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Apr 5, 2021
@Mark-Simulacrum
Copy link
Member

Both O0 and O1 only inline always_inline functions, so that's in line with expectations. As far as rust is concerned, O1 is essentially useless.

Hm, interesting. This seems somewhat unexpected, and may not be a good fit for Rust -- I guess we could tag things always_inline (which IIRC is still just a hint?) in O1 more eagerly?

This seems good to merge in the meantime though. @bors r+

@bors
Copy link
Contributor

bors commented Apr 5, 2021

📌 Commit 37498a1 has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 5, 2021
@bors
Copy link
Contributor

bors commented Apr 5, 2021

⌛ Testing commit 37498a1 with merge 58e7189...

@bors
Copy link
Contributor

bors commented Apr 5, 2021

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 58e7189 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 5, 2021
@bors bors merged commit 58e7189 into rust-lang:master Apr 5, 2021
@rustbot rustbot added this to the 1.53.0 milestone Apr 5, 2021
@joshtriplett joshtriplett deleted the unsafe-cell-always-inline branch April 5, 2021 08:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants