-
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
Always inline check in assert_unsafe_precondition
with cfg(debug_assertions)
#121196
Conversation
This comment has been minimized.
This comment has been minimized.
Can we just use cfg_attr to swap between inline never and always then put inline always on the |
I did that and it took 54s, sounds good. |
95b1f45
to
0f4db16
Compare
assert_unsafe_precondition
with cfg(debug_assertions)assert_unsafe_precondition
with cfg(debug_assertions)
…sertions) The current complexities in `assert_unsafe_precondition` are delicately balancing several concerns, among them compile times for the cases where there are no debug assertions. This comes at a large runtime cost when the assertions are enabled, making the debug assertion compiler a lot slower, which is very annoying. To avoid this, we always inline the check when building with debug assertions. Numbers (compiling stage1 library after touching core): - master: 80s - just adding `#[inline(always)]` to the `cfg(bootstrap)` `debug_assertions`: 67s - this: 54s So this seems like a good solution. I think we can still get the same run-time perf improvements for other users too by massaging this code further (see my other PR about adding `#[rustc_no_mir_inline]`) but this is a simpler step that solves the imminent problem of "holy shit my rustc is sooo slow". Funny consequence: This now means compiling the standard library with dbeug assertions makes it faster (than without, when using debug assertions downstream)!
0f4db16
to
03d03c6
Compare
@bors r+ |
…aethlin Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions) The current complexities in `assert_unsafe_precondition` are delicately balancing several concerns, among them compile times for the cases where there are no debug assertions. This comes at a large runtime cost when the assertions are enabled, making the debug assertion compiler a lot slower, which is very annoying. To avoid this, we always inline the check when building with debug assertions. Numbers (compiling stage1 library after touching core): - master: 80s - just adding `#[inline(always)]` to the `cfg(bootstrap)` `debug_assertions` (equivalent to a bootstrap bump (uhh, i just realized that i was on a slightly outdated master so this bump might have happened already), (rust-lang#121112)): 67s - this: 54s So this seems like a good solution. I think we can still get the same run-time perf improvements for other users too by massaging this code further (see my other PR about adding `#[rustc_no_mir_inline]` rust-lang#121114) but this is a simpler step that solves the imminent problem of "holy shit my rustc is sooo slow". Funny consequence: This now means compiling the standard library with dbeug assertions makes it faster (than without, when using debug assertions downstream)! r? `@saethlin` (or anyone else if someone wants to review this) fixes rust-lang#121110, supposedly
Rollup of 8 pull requests Successful merges: - rust-lang#121167 (resolve: Scale back unloading of speculatively loaded crates) - rust-lang#121196 (Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions)) - rust-lang#121206 (Top level error handling) - rust-lang#121223 (intrinsics::simd: add missing functions) - rust-lang#121241 (Implement `NonZero` traits generically.) - rust-lang#121242 (Generate `getelementptr` instead of `inttoptr` for `ptr::invalid`) - rust-lang#121278 (Remove the "codegen" profile from bootstrap) - rust-lang#121286 (Rename `ConstPropLint` to `KnownPanicsLint`) r? `@ghost` `@rustbot` modify labels: rollup
…aethlin Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions) The current complexities in `assert_unsafe_precondition` are delicately balancing several concerns, among them compile times for the cases where there are no debug assertions. This comes at a large runtime cost when the assertions are enabled, making the debug assertion compiler a lot slower, which is very annoying. To avoid this, we always inline the check when building with debug assertions. Numbers (compiling stage1 library after touching core): - master: 80s - just adding `#[inline(always)]` to the `cfg(bootstrap)` `debug_assertions` (equivalent to a bootstrap bump (uhh, i just realized that i was on a slightly outdated master so this bump might have happened already), (rust-lang#121112)): 67s - this: 54s So this seems like a good solution. I think we can still get the same run-time perf improvements for other users too by massaging this code further (see my other PR about adding `#[rustc_no_mir_inline]` rust-lang#121114) but this is a simpler step that solves the imminent problem of "holy shit my rustc is sooo slow". Funny consequence: This now means compiling the standard library with dbeug assertions makes it faster (than without, when using debug assertions downstream)! r? ``@saethlin`` (or anyone else if someone wants to review this) fixes rust-lang#121110, supposedly
Rollup of 8 pull requests Successful merges: - rust-lang#121167 (resolve: Scale back unloading of speculatively loaded crates) - rust-lang#121196 (Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions)) - rust-lang#121241 (Implement `NonZero` traits generically.) - rust-lang#121278 (Remove the "codegen" profile from bootstrap) - rust-lang#121286 (Rename `ConstPropLint` to `KnownPanicsLint`) - rust-lang#121291 (target: Revert default to the medium code model on LoongArch targets) - rust-lang#121302 (Remove `RefMutL` hack in `proc_macro::bridge`) - rust-lang#121318 (Trigger `unsafe_code` lint on invocations of `global_asm`) Failed merges: - rust-lang#121206 (Top level error handling) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#121196 - Nilstrieb:the-clever-solution, r=saethlin Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions) The current complexities in `assert_unsafe_precondition` are delicately balancing several concerns, among them compile times for the cases where there are no debug assertions. This comes at a large runtime cost when the assertions are enabled, making the debug assertion compiler a lot slower, which is very annoying. To avoid this, we always inline the check when building with debug assertions. Numbers (compiling stage1 library after touching core): - master: 80s - just adding `#[inline(always)]` to the `cfg(bootstrap)` `debug_assertions` (equivalent to a bootstrap bump (uhh, i just realized that i was on a slightly outdated master so this bump might have happened already), (rust-lang#121112)): 67s - this: 54s So this seems like a good solution. I think we can still get the same run-time perf improvements for other users too by massaging this code further (see my other PR about adding `#[rustc_no_mir_inline]` rust-lang#121114) but this is a simpler step that solves the imminent problem of "holy shit my rustc is sooo slow". Funny consequence: This now means compiling the standard library with dbeug assertions makes it faster (than without, when using debug assertions downstream)! r? ```@saethlin``` (or anyone else if someone wants to review this) fixes rust-lang#121110, supposedly
// time impact when debug assertions are disabled. | ||
// It is not clear whether that is the best solution, see #120848. | ||
#[cfg_attr(debug_assertions, inline(always))] | ||
#[cfg_attr(not(debug_assertions), inline(never))] |
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.
This checks cfg(debug_assertions)
which is different from intrinsics::debug_assertions
which is used to determine whether the function is even called. Shouldn't the comment explain why that mismatch is okay? It is certainly not obvious to me.
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.
Why wouldn't the difference be okay? Sure, the behavior isn't exactly the same, but users who enable that will get more checks in case they don't enable debug_assertions downstream but that seems okay. We should be able to remove this again after #121114 anyways, I mostly PRed this to avoid thinking in #121114, but I have done the thinking now.
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.
Why wouldn't the difference be okay?
There's a funny case to consider where debug assertions are disabled but intrinsics::debug_assertions
returns true. (There's theoretically also the dual case.) I would have expected the comment to acknowledge this and explain why what happens in that case is what we want.
We should be able to remove this again after #121114 anyways
Ah, if this is temporary then never mind. :)
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.
There's a funny case to consider where debug assertions are disabled but intrinsics::debug_assertions returns true.
when building core
, that cannot happen. When building user code, yes, that's actually the expected and normal path, core without debug assertions, but debug assertions in the user case.
The current complexities in
assert_unsafe_precondition
are delicately balancing several concerns, among them compile times for the cases where there are no debug assertions. This comes at a large runtime cost when the assertions are enabled, making the debug assertion compiler a lot slower, which is very annoying.To avoid this, we always inline the check when building with debug assertions.
Numbers (compiling stage1 library after touching core):
#[inline(always)]
to thecfg(bootstrap)
debug_assertions
(equivalent to a bootstrap bump (uhh, i just realized that i was on a slightly outdated master so this bump might have happened already), (Inline cfg(bootstrap) version ofdebug_assertions
intrinsic #121112)): 67sSo this seems like a good solution. I think we can still get the same run-time perf improvements for other users too by massaging this code further (see my other PR about adding
#[rustc_no_mir_inline]
#121114) but this is a simpler step that solves the imminent problem of "holy shit my rustc is sooo slow".Funny consequence: This now means compiling the standard library with dbeug assertions makes it faster (than without, when using debug assertions downstream)!
r? @saethlin (or anyone else if someone wants to review this)
fixes #121110, supposedly