Lock step loop codegen issue

[bluss]

The original issue is the performance regression in #38021 when using the TrustedLen specialization of Extend<&T> for Vec.

In pseudocode you can describe their difference like this:

extend_from_slice:
for i in 0..len {
    dst[i] = src[i];
}

extend/TrustedLen:
while src != src_end {
    *dst++ = *src++;
}

A reduced case to demonstrate the issue is https://gist.github.com/bluss/61c32daae1bd31d9d7605983df3ace5f

[bluss]

This code looks like enough to reproduce in current nightly:

pub fn extend_1(v: &mut Vec<u8>, data: &[u8; 16]) {
    v.extend(data)
}

[bluss]

Reduced to not use so much library code (playground link)

Replacing .map(|&x| x) with a manual dereference of the element in place resolves the issue.

fn extend(v: &mut Vec<u8>, input: &[u8]) {
    v.reserve(input.len());
    unsafe {
        let mut dst = v.as_mut_ptr().offset(v.len() as isize);
        let mut iter = input.iter().map(|&x| x);
        while let Some(elt) = iter.next() {
            *dst = elt;
            dst = dst.offset(1);
        }
        let new_len = v.len() + input.len();
        v.set_len(new_len);
    }
}

#[no_mangle]
pub fn extend_1(v: &mut Vec<u8>, data: &[u8; 16]) {
    extend(v, data);
}

[bluss]

The reduced case above can be fixed like this (look at dst and i).

fn extend(v: &mut Vec<u8>, input: &[u8]) {
    v.reserve(input.len());
    unsafe {
        let dst = v.as_mut_ptr();
        let mut i = v.len() as isize;
        let mut iter = input.iter().map(|&x| x);
        while let Some(elt) = iter.next() {
            *dst.offset(i) = elt;
            i += 1;
        }
        let new_len = v.len() + input.len();
        v.set_len(new_len);
    }
}

but this fix does not seem to work to resolve the serialization regression in extend/TrustedLen.

[saethlin]

I extracted what I think is supposed to be the slow and fast version from the playground link above. It looks like this was fixed with rustc 1.20: https://godbolt.org/z/r8vcx64Kx Squinting at the LLVM IR in the gist linked above, it seems like the same pile of 1-byte moves that are emitted by rustc 1.19, but collapsed down by rust 1.20.

cc @alice-i-cecile