-
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
interpret: don't rely on ScalarPair for overflowed arithmetic #98627
Conversation
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
r? @lcnr (rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit a863894797f329841331df301bdaf275c0e3ff94 with merge 57aca588d42161a2fd53f97a85fc4eb9f62f8e38... |
☀️ Try build successful - checks-actions |
Queued 57aca588d42161a2fd53f97a85fc4eb9f62f8e38 with parent baf382e, future comparison URL. |
That is strange, is this making const-prop worse? |
Finished benchmarking commit (57aca588d42161a2fd53f97a85fc4eb9f62f8e38): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking 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 Footnotes |
Cg_clif makes the same assumption with respect to the |
As expected, the CTFE benchmark is not happy. We probably should go with @eddyb's proposal of checking the |
Oh yea this affects const prop. Const prop likely doesn't handle locals backed by an alloc properly and optimizes/lints less |
129fe71
to
9eabc3b
Compare
All right, I brought back the old code path. It is not used in debug builds. |
Aand I guess CI is using a debug build. Argh. |
This comment has been minimized.
This comment has been minimized.
Well, this should fix CI. The only problem is that now the new code path is fully untested... |
i am fine with that r=me unless you want to try something else |
let pair = Immediate::ScalarPair(val.into(), Scalar::from_bool(overflowed).into()); | ||
self.write_immediate(pair, dest)?; | ||
} else { | ||
// With randomized layout, `(int, bool)` might cease to be a `ScalarPair`, so we have to |
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.
maybe explicitly assert that we're using -Zrandomize-layout
(or however the flag is called) here?
📌 Commit 0850bad has been approved by |
Sure, I can totally try to test layout randomization in a later PR |
☀️ Test successful - checks-actions |
Finished benchmarking commit (27eb6d7): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
This is for #97861.
Cc @eddyb
I would like to avoid making this depend on
dest.layout.abi
to avoid a branch that we are not usually covering both sides of. Though OTOH this seems like fairly straight-forward code. But let's benchmark this option first to see how bad that extraforce_allocation
really is.