Missed optimization: repeated pointer increments don't compile to a memcpy

[timvermeulen]

pub unsafe fn copy(slice: &[u8], dst: *mut u8) {
    let mut src = slice.as_ptr();
    let mut dst = dst;

    for _ in 0..slice.len() {
        *dst = *src;
        src = src.add(1);
        dst = dst.add(1);
    }
}

This doesn't currently compile to a memcpy (Godbolt).

I figured this was worth filing because this seems to be the main reason that a naive iter::Zip implementation isn't optimal, which is why it's implemented the way it is.

[the8472]

since pointers can point into the same allocation it would have to be a memmove in the general case. Nevermind, aliasing rules allows memcpy.

[cynecx]

pub unsafe fn copy(slice: &[u8], dst: *mut u8) {
    let src = slice.as_ptr();
    for i in 0..slice.len() {
        *dst.add(i) = *src.add(i);
    }
}

This does (https://godbolt.org/z/MdgeTL).

[timvermeulen]

@cynecx Indeed, that is exactly what Zip currently boils down to using the private TrustedRandomAccess trait. An attempt to replace it lead me to the snippet above. It would be really nice if repeated pointer increments would optimize in the same way because that's essentially what slice::{Iter, IterMut}::next does.

[cynecx]

@timvermeulen Fwiw LLVM isn't doing a great job at detecting this particular pattern: https://godbolt.org/z/TW2bJH (C++).

[nikic]

This is detected as a memcpy on nightly, presumably due to LLVM 12 upgrade.