[DRAFT] make panic overflow messages include values#154231
[DRAFT] make panic overflow messages include values#154231asquared31415 wants to merge 3 commits intorust-lang:mainfrom
Conversation
|
Generics + inline(never) share the upstream instantiation as long as there is one, so you shouldn't need the full set of functions. I suspect extending to 128-bits is going to be too much impact (64 bits would probably be close to free, but 128 seems likely to not be). @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.
[DRAFT] make panic overflow messages include values
|
Agreed, the extension to 128 bit was part that I liked least about this implementation. If the binary size impact of actually doing the calls is bad, I also might try providing a 64 or even 32 bit version (but not 8 or 16) and only extend up to the smallest size necessary for the actual type. Then for the majority of cases it could be one native register per argument, instead of 2 registers per argument in every case. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (9e39c5f): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient 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.6%, secondary 0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.3%, secondary -0.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.1%, secondary 0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 485.484s -> 488.066s (0.53%) |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
FWIW I don't think rustc-perf is any useful here. The compiler is currently compile with overflow-checks disabled and any benchmarks like this mix potential overhead at runtime from having to spend more time compiling. As such rustc-perf compile-time benchmarks can't really be used meaningfully here. I don't think we have a good substitute out-of-the-box. |
|
☔ The latest upstream changes (presumably #154253) made this pull request unmergeable. Please resolve the merge conflicts. |
Changes the panic overflow messages at runtime from the form "attempted to add with overflow" to be more like the const eval overflow messages: "attempt to compute `200 + 100` which would overflow".
Needs perf run to evaluate binary size and compile time impact.
Also should probably implement some of the other overflow panic messages, such as unary negation, and maybe div/rem by 0 (though that one is probably less useful)
r? @Mark-Simulacrum
I have a couple different ideas for implementations if the impact is too bad. I could either make the functions generic and instantiate them in core, or manually make a function that takes every int pair (
panic_add_overflow_u8,panic_add_overflow_u16, ...) if the generics are causing the functions to get included in downstream crates.ref https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Improved.20Overflow.20Panic.20Messages