[perf trials] how bad would it be if panic handlers returned unit#157424
[perf trials] how bad would it be if panic handlers returned unit#157424jdonszelmann wants to merge 2 commits into
Conversation
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
[perf trials] how bad would it be if panic handlers returned unit
| #[cold] | ||
| #[track_caller] | ||
| pub(in crate::num) const fn add() -> ! { | ||
| pub(in crate::num) const fn add() -> () { |
There was a problem hiding this comment.
functions in the standard library may return unit
| ); | ||
| self.diverge_from(block); | ||
| if false { | ||
| self.diverge_from(block); |
There was a problem hiding this comment.
we no longer insert a diverge in mir when we generate an assertion (this can be scoped more in the future to just integer overflow related assertions)
| None => imp::overflow_panic::cast_integer(), | ||
| None => { | ||
| imp::overflow_panic::cast_integer(); | ||
| 0 |
There was a problem hiding this comment.
returns default values. highly dubious to do this in the strict integer operations, just want to see what it's gaining us. The final version probably won't do this in strict ops
| @@ -193,24 +193,24 @@ pub mod panic_const { | |||
| panic_const_neg_overflow = "attempt to negate with overflow", | |||
| panic_const_shr_overflow = "attempt to shift right with overflow", | |||
| panic_const_shl_overflow = "attempt to shift left with overflow", | |||
There was a problem hiding this comment.
overflow related panic handlers no longer return never, unit instead
| // CHECK: add i8 %b, %a | ||
| // DEBUG: icmp ult i8 [[zero:[^,]+]], %a | ||
| // DEBUG: call core::num::imp::overflow_panic::add | ||
| // DEBUG: unreachable |
There was a problem hiding this comment.
this was our one test checking this, even with overflow checks we won't emit unreachable anymore now :)
|
Now the question is, what is the divergence gaining us, if anything :3 |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (bd63bd3): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. Next, please: If you can, justify the regressions found in this try perf run in writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 1.0%, secondary -1.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -5.0%, secondary -3.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.1%, secondary 0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 511.14s -> 512.329s (0.23%) |
|
how is this such a big improvement???? |
|
surely this is noise |
|
match-stress at least spends a fair bit less time in check_match: https://perf.rust-lang.org/detailed-query.html?commit=bd63bd3cd3a3e3e7ad046f6868a063ebe8a24c54&benchmark=match-stress-check&scenario=full&backend=llvm&target=x86_64-unknown-linux-gnu&base_commit=49b19d32b9f01a5aa606f3bf2e90e6e0aa462c03&sort=timeDelta |
|
☔ The latest upstream changes (presumably #147250) made this pull request unmergeable. Please resolve the merge conflicts. |
r? @ghost