-
Couldn't load subscription status.
- Fork 13.9k
Rollup of 5 pull requests #36552
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
Rollup of 5 pull requests #36552
Conversation
Go back on half the specialization, the part that changed the Zip
struct's fields themselves depending on the types of the iterators.
This means that the Zip iterator will always carry two usize fields,
which are unused. If a whole for loop using a .zip() iterator is
inlined, these are simply removed and have no effect.
The same improvement for Zip of for example slice iterators remain, and
they still optimize well. However, like when the specialization of zip
was merged, the compiler is still very sensistive to the exact context.
For example this code only autovectorizes if the function is used, not
if the code in zip_sum_i32 is inserted inline it was called:
```
fn zip_sum_i32(xs: &[i32], ys: &[i32]) -> i32 {
let mut s = 0;
for (&x, &y) in xs.iter().zip(ys) {
s += x * y;
}
s
}
fn zipdot_i32_default_zip(b: &mut test::Bencher)
{
let xs = vec![1; 1024];
let ys = vec![1; 1024];
b.iter(|| {
zip_sum_i32(&xs, &ys)
})
}
```
Include a test that checks that Zip<T, U> is covariant w.r.t. T and U.
This introduces a new `InstCombine` pass for us to place such peephole optimizations.
…ition, r=alexcrichton Remove data structure specialization for .zip() iterator Go back on half the specialization, the part that changed the Zip struct's fields themselves depending on the types of the iterators. Previous PR: rust-lang#33090 This means that the Zip iterator will always carry two usize fields, which are sometimes unused. If a whole for loop using a .zip() iterator is inlined, these are simply removed and have no effect. The same improvement for Zip of for example slice iterators remain, and they still optimize well. However, like when the specialization of zip was merged, the compiler is still very sensistive to the exact context. For example this code only autovectorizes if the function is used, not if the code in zip_sum_i32 is inserted inline where it was called: ```rust fn zip_sum_i32(xs: &[i32], ys: &[i32]) -> i32 { let mut s = 0; for (&x, &y) in xs.iter().zip(ys) { s += x * y; } s } fn zipdot_i32_default_zip(b: &mut test::Bencher) { let xs = vec![1; 1024]; let ys = vec![1; 1024]; b.iter(|| { zip_sum_i32(&xs, &ys) }) } ``` Include a test that checks that `Zip<T, U>` is covariant w.r.t. T and U. Fixes rust-lang#35727
…eddyb Workaround rust-lang#34427 by using memset of 0 on ARM to set the discriminant. Workaround rust-lang#34427 by using memset of 0 on ARM to set the discriminant.
librustc_mir: Remove `&*x` when `x` has a reference type. This introduces a new `InstCombine` pass for us to place such peephole optimizations. r? @eddyb
fix top level attr spans issue rust-lang#36530 ?r @jonathandturner
Remove stray println! when invoking error E0316 Removed a wild println! statement that has been here for over a year and a half. Closes rust-lang#36543
|
r? @Aatch (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors r+ p=10 |
|
📌 Commit 574b779 has been approved by |
|
⌛ Testing commit 574b779 with merge 7f4ae02... |
|
💔 Test failed - auto-mac-cross-ios-opt |
|
☔ The latest upstream changes (presumably #36388) made this pull request unmergeable. Please resolve the merge conflicts. |
&*xwhenxhas a reference type. #36504, fix top level attr spans #36539, Remove stray println! when invoking error E0316 #36545