-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 intrinsics::debug_assertions in debug_assert_nounwind #120863
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Improve precondition checks for unchecked slice indexing r? `@ghost`
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (8389ea2): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 666.679s -> 665.456s (-0.18%) |
This comment has been minimized.
This comment has been minimized.
8707370
to
9c1c07b
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Improve precondition checks for unchecked slice indexing r? `@ghost`
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (f759bae): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 666.058s -> 667.485s (0.21%) |
d3a5063
to
8561678
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
I think I've recreated the MacOS build locally but without a crash. Maybe it's no longer reproducible? @bors r=the8472 |
☀️ Test successful - checks-actions |
Finished benchmarking commit (2b43e75): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 640.822s -> 641.255s (0.07%) |
Not what we saw before. I'll look into this later. |
Tweak inlining attributes for slice indexing Doing some experiments in response to this unexpected regression: rust-lang#120863 (comment) I expect the opt changes to be addressed by something like reviving rust-lang#91222. The debug changes are what I'm interested in. Codegen tests will probably fail from time to time in this PR, I will fix them up later but also I don't trust the opt-level-z one: rust-lang#119878 (comment) r? `@ghost`
…iler-errors Ignore less tests in debug builds Since rust-lang#120594 and rust-lang#120863, nearly all UB-detecting debug assertions get compiled out of code that is monomorphized by a crate built with debug assertions disabled. Which means that if we default all our codegen tests to `-Cdebug-assertions=no`, most of them work just fine against a sysroot built with debug assertions. I also tried to explain a bit better why some tests need to be skipped, for those that still need to be skipped.
Rollup merge of rust-lang#121531 - saethlin:ignore-less-debug, r=compiler-errors Ignore less tests in debug builds Since rust-lang#120594 and rust-lang#120863, nearly all UB-detecting debug assertions get compiled out of code that is monomorphized by a crate built with debug assertions disabled. Which means that if we default all our codegen tests to `-Cdebug-assertions=no`, most of them work just fine against a sysroot built with debug assertions. I also tried to explain a bit better why some tests need to be skipped, for those that still need to be skipped.
#[rustc_macro_transparency = "semitransparent"] | ||
pub macro debug_assert_nounwind { | ||
($cond:expr $(,)?) => { | ||
if $crate::cfg!(debug_assertions) { | ||
if $crate::intrinsics::debug_assertions() { |
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.
I think this violates the contract for intrinsics::debug_assertions
. We said this should only be used if there is anyway UB (meaning: language UB) when the condition is violated, but debug_assert_nounwind
is used in places where there is only library UB.
EDIT: #121583 adds some FIXMEs.
Ignore less tests in debug builds Since rust-lang/rust#120594 and rust-lang/rust#120863, nearly all UB-detecting debug assertions get compiled out of code that is monomorphized by a crate built with debug assertions disabled. Which means that if we default all our codegen tests to `-Cdebug-assertions=no`, most of them work just fine against a sysroot built with debug assertions. I also tried to explain a bit better why some tests need to be skipped, for those that still need to be skipped.
@saethlin I'm doing perf triage - it seems the perf regression here hasn't yet been addressed. Looking at the profiles, it seems that most of the regressions are in codegen which I suppose makes sense given the nature of the change. Would you be able to either open an issue or a PR addressing the perf concerns in some form or perhaps argue for why the regression is acceptable at the current time? |
@rylev The perf run in this PR which doesn't have the But most of the code in this PR is going to be overwritten by #121662. The primary cause of compile-time overhead in this PR is that the checks here are never outlined, which is how I mitigated the compile-time overhead of the first round of checks I added in #120594. That will be fixed by #121662. All PRs with these checks as they are currently written interact strongly with tweaks to codegen like #121421 and #120650 because these checks insert IR patterns like In terms of "what to do next" I would like #121662 to land because it significantly changes what IR we generate. Then I intend to create a perf experiment PR that cfg's out all these checks to measure their compile-time impact. This whole feature has been landed in relatively small parts across now between 5 and 7 PRs and I'm not sure their perf impact is separable. Also last night I came up with an idea for how to fix the impact that these checks have on MIR inlining, which might fix all the compile-time overhead in the opt benchmarks. |
Upgrades the Rust toolchain to `nightly-2024-02-25`. The Rust compiler PRs that triggered changes in this upgrades are: * rust-lang/rust#121209 * rust-lang/rust#121309 * rust-lang/rust#120863 * rust-lang/rust#117772 * rust-lang/rust#117658 With rust-lang/rust#121309 some intrinsics became inlineable so their names became qualified. This made our `match` on the intrinsic name to fail in those cases, leaving them as unsupported constructs as in this example: ``` warning: Found the following unsupported constructs: - _RNvNtCscyGW2MM2t5j_4core10intrinsics8unlikelyCs1eohKeNmpdS_5arith (3) - caller_location (1) - foreign function (1) Verification will fail if one or more of these constructs is reachable. See https://model-checking.github.io/kani/rust-feature-support.html for more details. [...] Failed Checks: _RNvNtCscyGW2MM2t5j_4core10intrinsics8unlikelyCs1eohKeNmpdS_5arith is not currently supported by Kani. Please post your example at https://github.com/model-checking/kani/issues/new/choose File: "/home/ubuntu/.rustup/toolchains/nightly-2024-02-18-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs", line 25, in core::num::<impl i8>::checked_add ``` We use `trimmed_name()` to work around this, but that may include type arguments if the intrinsic is defined on generics. So in those cases, we just take the first part of the name so we can keep the rest as before. Resolves #3044
Use intrinsics::debug_assertions in debug_assert_nounwind This is the first item in rust-lang/rust#120848. Based on the benchmarking in this PR, it looks like, for the programs in our benchmark suite, enabling all these additional checks does not introduce significant compile-time overhead, with the single exception of `Alignment::new_unchecked`. Therefore, I've added `#[cfg(debug_assertions)]` to that one call site, so that it remains compiled out in the distributed standard library. The trailing commas in the previous calls to `debug_assert_nounwind!` were causing the macro to expand to `panic_nouwnind_fmt`, which requires more work to set up its arguments, and that overhead alone is measured between this perf run and the next: rust-lang/rust#120863 (comment)
Use intrinsics::debug_assertions in debug_assert_nounwind This is the first item in rust-lang/rust#120848. Based on the benchmarking in this PR, it looks like, for the programs in our benchmark suite, enabling all these additional checks does not introduce significant compile-time overhead, with the single exception of `Alignment::new_unchecked`. Therefore, I've added `#[cfg(debug_assertions)]` to that one call site, so that it remains compiled out in the distributed standard library. The trailing commas in the previous calls to `debug_assert_nounwind!` were causing the macro to expand to `panic_nouwnind_fmt`, which requires more work to set up its arguments, and that overhead alone is measured between this perf run and the next: rust-lang/rust#120863 (comment)
This is the first item in #120848.
Based on the benchmarking in this PR, it looks like, for the programs in our benchmark suite, enabling all these additional checks does not introduce significant compile-time overhead, with the single exception of
Alignment::new_unchecked
. Therefore, I've added#[cfg(debug_assertions)]
to that one call site, so that it remains compiled out in the distributed standard library.The trailing commas in the previous calls to
debug_assert_nounwind!
were causing the macro to expand topanic_nouwnind_fmt
, which requires more work to set up its arguments, and that overhead alone is measured between this perf run and the next: #120863 (comment)