-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Make codegen choose whether to emit overflow checks #107921
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
Conversation
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
2f6b9ea
to
cd152c4
Compare
This PR changes MIR cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @celinval, @vakaras |
/// When overflow checking is disabled and we are generating run-time code, the `Overflow*` | ||
/// variants of this terminator are codegened as simple `goto target`. |
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 is very suspicious. The spec of a language should never mention "codegen". Shouldn't this just say "when overflow checking is disabled, the Overflow*
variants behave as goto target
"? And then the interpreter should also implement those semantics.
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.
Ah, this is partially copied from the existing CheckedBinaryOp docs, but the partial copy made it even more confusing. That existing doc should also be adjusted...
/// When overflow checking is disabled and we are generating run-time code, the `Overflow*` | |
/// variants of this terminator are codegened as simple `goto target`. | |
/// When overflow checking is disabled and this is run-time MIR (as opposed to | |
/// compile-time MIR that is used for CTFE), the `Overflow*` | |
/// variants of this terminator behave as `goto target`. |
Having semantic differences between runtime and compiletime MIR is not great but is not new either.
And the interpreter will still need adjustments since Miri executes runtime MIR.
I don't understand what you mean by this. Without overflow checks MR building should generate non-checked BinaryOp, no? |
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
17ef3f4
to
b731317
Compare
Libraries may be built with overflow checks enabled, so emit MIR with checked operations, and then that MIR may be codegened into a non-checked compilation (through inlining or monomorphization). In that case, the downstream crate dictates the behaviour and must remove the overflow checks. As for the optimization, it refers to this code. rust/compiler/rustc_codegen_ssa/src/mir/rvalue.rs Lines 654 to 661 in 5b45024
|
I don't think that is accurate in general -- libraries are built with the flags determined by the main crate cargo builds. There is one special exception, and it is the
Ah, that's what I missed, thanks. Would be good to add a comment saying that this is just an optimization now since the assertion anyway becomes a NOP. |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit c9cd5659b54a45ce4a6cddf03de5a11cd8de15bb with merge fca0d6e1a6baaaf9af26313a4bd254bc19f51f39... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (fca0d6e1a6baaaf9af26313a4bd254bc19f51f39): comparison URL. Overall result: no relevant changes - 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 benchmark run did not return any relevant results for this metric. 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.
|
b729d06
to
7e795bd
Compare
@bors r+ |
⌛ Testing commit 9f6c1df with merge 2e62ed984d82cb78475414ccb28aac6b0a08bee0... |
💔 Test failed - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
☀️ Test successful - checks-actions |
Finished benchmarking commit (7aa413d): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. |
ConstProp and DataflowConstProp currently have a specific code path not to propagate constants when they overflow. This is meant to have the correct behaviour when inlining from a crate with overflow checks (like
core
) into a crate compiled without.This PR shifts the behaviour change to the
Assert(Overflow*)
MIR terminators: if the crate is compiled without overflow checks, just skip emitting the assertions. This is already what happens withOverflowNeg
.This allows ConstProp and DataflowConstProp to transform
CheckedBinaryOp(Add, u8::MAX, 1)
intoconst (0, true)
, and let codegen ignore thetrue
.The interpreter is modified to conform to this behaviour.
Fixes #35310