Skip to content
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

Closed
wants to merge 10 commits into from
Closed

Conversation

bluss and others added 10 commits September 15, 2016 13:00
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
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
@rust-highfive
Copy link
Collaborator

r? @Aatch

(rust_highfive has picked a reviewer for you, use r? to override)

@Manishearth
Copy link
Member Author

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Sep 17, 2016

📌 Commit 574b779 has been approved by Manishearth

@bors
Copy link
Contributor

bors commented Sep 17, 2016

⌛ Testing commit 574b779 with merge 7f4ae02...

@bors
Copy link
Contributor

bors commented Sep 17, 2016

💔 Test failed - auto-mac-cross-ios-opt

@bors
Copy link
Contributor

bors commented Sep 20, 2016

☔ The latest upstream changes (presumably #36388) made this pull request unmergeable. Please resolve the merge conflicts.

@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants