-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Add invariant to Vec::pop that len < cap if pop successful #114370
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
Without codegen test this is likely to regress at some point. |
let's check the perf impact @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit 32a0bf62062fcc99d927e2611eeefe2f62bf96f4 with merge 09bf8a0a3be933b7f221bdc99f8fdfe5e8a0306e... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (09bf8a0a3be933b7f221bdc99f8fdfe5e8a0306e): comparison URL. Overall result: ❌ regressions - 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.
CyclesThis benchmark run did not return any relevant results for this metric. 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: 649.933s -> 651.065s (0.17%) |
r? @scottmcm I agree with @mati865 that this (like all @rustbot author (That way when LLVM gets smarter or the code around it changes, people can try removing them again -- like in #111447 -- and the codegen test ensures that doesn't regress things.) |
I've added a codegen test on the LLVM IR. I was unsure whether to add it as an LLVM-IR codegen or assembly codegen test. I chose the first because it felt more portable, but the second would have been closer to the spirit ("it should compile to a noop"). Let me know if you want me to change. |
tests/codegen/vec_pop_push_noop.rs
Outdated
// CHECK-NEXT: getelementptr | ||
// CHECK-NEXT: load | ||
// CHECK-NEXT: icmp | ||
// CHECK-NEXT: tail call |
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.
Hmm, the way this is written it feels a bit too specific, in that lots of little changes could make it fail (like bb3
getting a different name), but also that this tail call
could be to something that reallocates and it'd pass.
Can you maybe focus it in a bit on what the critical part is?
Perhaps have another function in here showing that push
normally can call __rust_realloc
, but that this one doesn't?
A possible starting point:
#[no_mangle]
// CHECK-LABEL: @noop(
pub fn noop(v: &mut Vec<u8>) {
// CHECK-NOT: __rust_alloc
// CHECK-NOT: __rust_realloc
// CHECK-NOT: call
// CHECK: tail call void @llvm.assume
// CHECK-NOT: __rust_alloc
// CHECK-NOT: __rust_realloc
// CHECK-NOT: call
if let Some(x) = v.pop() {
v.push(x)
}
}
#[no_mangle]
// CHECK-LABEL: @push_byte(
pub fn push_byte(v: &mut Vec<u8>) {
// CHECK: call {{.+}} @__rust_alloc(
// CHECK: call {{.+}} @__rust_realloc(
v.push(3);
}
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.
Hmm, maybe it'll have to look at reserve_for_push
instead of the allocation functions directly...
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.
Hi,
I see your point but wouldn't it then be better to go for a codegen test on the assembly itself which is empty?
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.
No, because everything should be codegen tests where possible -- random permutations of temporary assembly registers and differing calling conventions make assembly tests something that's a last resort.
@bors r+ rollup=never |
☀️ Test successful - checks-actions |
Finished benchmarking commit (49691b1): comparison URL. Overall result: ✅ improvements - no action needed@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: 626.726s -> 627.292s (0.09%) |
54: Pull upstream master 2023 10 17 r=pietroalbini a=Veykril * rust-lang/rust#116196 * rust-lang/rust#116824 * rust-lang/rust#116822 * rust-lang/rust#116477 * rust-lang/rust#116826 * rust-lang/rust#116820 * rust-lang/rust#116811 * rust-lang/rust#116808 * rust-lang/rust#116805 * rust-lang/rust#116800 * rust-lang/rust#116798 * rust-lang/rust#116754 * rust-lang/rust#114370 * rust-lang/rust#116804 * rust-lang/rust#116802 * rust-lang/rust#116790 * rust-lang/rust#116786 * rust-lang/rust#116709 * rust-lang/rust#116430 * rust-lang/rust#116257 * rust-lang/rust#114157 * rust-lang/rust#116731 * rust-lang/rust#116550 * rust-lang/rust#114330 * rust-lang/rust#116724 * rust-lang/rust#116782 * rust-lang/rust#116776 * rust-lang/rust#115955 * rust-lang/rust#115196 * rust-lang/rust#116775 * rust-lang/rust#114589 * rust-lang/rust#113747 * rust-lang/rust#116772 * rust-lang/rust#116771 * rust-lang/rust#116760 * rust-lang/rust#116755 * rust-lang/rust#116732 * rust-lang/rust#116522 * rust-lang/rust#116341 * rust-lang/rust#116172 * rust-lang/rust#110604 * rust-lang/rust#110729 * rust-lang/rust#116527 * rust-lang/rust#116688 * rust-lang/rust#116757 * rust-lang/rust#116753 * rust-lang/rust#116748 * rust-lang/rust#116741 * rust-lang/rust#116594 * rust-lang/rust#116691 * rust-lang/rust#116643 * rust-lang/rust#116683 * rust-lang/rust#116635 * rust-lang/rust#115515 * rust-lang/rust#116742 * rust-lang/rust#116661 * rust-lang/rust#116576 * rust-lang/rust#116540 * rust-lang/rust#116352 * rust-lang/rust#116737 * rust-lang/rust#116730 * rust-lang/rust#116723 * rust-lang/rust#116715 * rust-lang/rust#116603 * rust-lang/rust#116591 * rust-lang/rust#115439 * rust-lang/rust#116264 * rust-lang/rust#116727 * rust-lang/rust#116704 * rust-lang/rust#116696 * rust-lang/rust#116695 * rust-lang/rust#116644 * rust-lang/rust#116630 * rust-lang/rust#116728 * rust-lang/rust#116689 * rust-lang/rust#116679 * rust-lang/rust#116618 * rust-lang/rust#116577 * rust-lang/rust#115653 * rust-lang/rust#116702 * rust-lang/rust#116015 * rust-lang/rust#115822 * rust-lang/rust#116407 * rust-lang/rust#115719 * rust-lang/rust#115524 * rust-lang/rust#116705 * rust-lang/rust#116645 * rust-lang/rust#116233 * rust-lang/rust#115108 * rust-lang/rust#116670 * rust-lang/rust#116676 * rust-lang/rust#116666 Co-authored-by: Benoît du Garreau <[email protected]> Co-authored-by: Colin Finck <[email protected]> Co-authored-by: Ian Jackson <[email protected]> Co-authored-by: Joshua Liebow-Feeser <[email protected]> Co-authored-by: León Orell Valerian Liehr <[email protected]> Co-authored-by: Trevor Gross <[email protected]> Co-authored-by: Evan Merlock <[email protected]> Co-authored-by: joboet <[email protected]> Co-authored-by: Ralf Jung <[email protected]> Co-authored-by: DaniPopes <[email protected]> Co-authored-by: Mark Rousskov <[email protected]> Co-authored-by: onur-ozkan <[email protected]> Co-authored-by: Nicholas Nethercote <[email protected]> Co-authored-by: The 8472 <[email protected]> Co-authored-by: Samuel Thibault <[email protected]> Co-authored-by: reez12g <[email protected]> Co-authored-by: Jakub Beránek <[email protected]>
…cap, r=<try> Add invariant to VecDeque::pop_* that len < cap if pop successful Similar to rust-lang#114370 for VecDeque instead of Vec. I initially come from rust-itertools/itertools#899 where we noticed that `pop_front;push_back;` was slower than expected so `@scottmcm` suggested I file an issue which lead to https://internals.rust-lang.org/t/vecdeque-pop-front-push-back/20483 where **kornel** mentionned rust-lang#114334 (fixed by rust-lang#114370). This is my first time with codegen tests, I based the test on what was done for Vec.
…e_cap, r=Nilstrieb Add invariant to VecDeque::pop_* that len < cap if pop successful Similar to rust-lang#114370 for VecDeque instead of Vec. I initially come from rust-itertools/itertools#899 where we noticed that `pop_front;push_back;` was slower than expected so `@scottmcm` suggested I file an issue which lead to https://internals.rust-lang.org/t/vecdeque-pop-front-push-back/20483 where **kornel** mentionned rust-lang#114334 (fixed by rust-lang#114370). This is my first time with codegen tests, I based the test on what was done for Vec.
…e_cap, r=Nilstrieb Add invariant to VecDeque::pop_* that len < cap if pop successful Similar to rust-lang#114370 for VecDeque instead of Vec. I initially come from rust-itertools/itertools#899 where we noticed that `pop_front;push_back;` was slower than expected so `@scottmcm` suggested I file an issue which lead to https://internals.rust-lang.org/t/vecdeque-pop-front-push-back/20483 where **kornel** mentionned rust-lang#114334 (fixed by rust-lang#114370). This is my first time with codegen tests, I based the test on what was done for Vec.
Rollup merge of rust-lang#123089 - Philippe-Cholet:vecdeque_pop_assume_cap, r=Nilstrieb Add invariant to VecDeque::pop_* that len < cap if pop successful Similar to rust-lang#114370 for VecDeque instead of Vec. I initially come from rust-itertools/itertools#899 where we noticed that `pop_front;push_back;` was slower than expected so `@scottmcm` suggested I file an issue which lead to https://internals.rust-lang.org/t/vecdeque-pop-front-push-back/20483 where **kornel** mentionned rust-lang#114334 (fixed by rust-lang#114370). This is my first time with codegen tests, I based the test on what was done for Vec.
Fixes: #114334