Suboptimal generated code for testing that a &[u8; 4] contains all zeros

[dbdr]

I expected comparing a [u8; 4] to [0; 4] to generate code identical to testing a u32 is 0, and indeed it is the case when comparing values. However when dereferencing is involved the code is longer:

pub fn test_u32_ref(data: &u32) -> bool {
    *data == 0
}

pub fn test_u8array_ref(data: &[u8; 4]) -> bool {
    *data == [0; 4]
}

gives:

example::test_u32_ref:
        cmp     dword ptr [rdi], 0
        sete    al
        ret

example::test_u8array_ref:
        lea     rax, [rip + .L__unnamed_1]
        cmp     rdi, rax
        je      .LBB1_1
        cmp     dword ptr [rdi], 0
        sete    al
        ret
.LBB1_1:
        mov     al, 1
        ret

.L__unnamed_1:
        .zero   4

https://godbolt.org/z/3GaUfy

Transmuting to u32 gives the optimized code:

pub fn test_u8array_ref_transmute(data: &[u8; 4]) -> bool {
    let data = unsafe { std::mem::transmute::<[u8; 4], u32>(*data) };
    data == 0
}

This issue has been assigned to @samrat via this comment.

[steffahn]

As far as I can tell, this comes from an “optimization” in the source code of comparing slices:
https://doc.rust-lang.org/src/core/slice/mod.rs.html#5833

impl<A> SlicePartialEq<A> for [A]
where
    A: PartialEq<A> + BytewiseEquality,
{
    fn equal(&self, other: &[A]) -> bool {
        if self.len() != other.len() {
            return false;
        }
// **** THIS PART vv
        if self.as_ptr() == other.as_ptr() {
            return true;
        }
// **** THIS PART ^^
        unsafe {
            let size = mem::size_of_val(self);
            memcmp(self.as_ptr() as *const u8, other.as_ptr() as *const u8, size) == 0
        }
    }
}

[steffahn]

If you call the function with (&[0;4]) (godbolt) this saves the need to read anything from memory (not that that’s really worth it, although it technically will be an unaligned read, I don’t know how slow those can be; also with an [u32; 1] it will even get rid of the conditional jump and always execute both things: https://godbolt.org/z/2KwUeQ, perhaps because of better alignment, who knows ^^).

[Mark-Simulacrum]

FWIW, you do not need a transmute, https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.from_ne_bytes will do the same (and is safe).

I'm uncertain how much the ptr-equality check there buys us - obviously, in some cases, it can be a big win, but I suspect the common case in most code isn't comparing literally the same slice.

This was added in #61665 with libs team approval; unfortunately the benchmark results are gone now -- I would expect it to have little impact on the vast majority of cases though, since it's a really cheap comparison in general. In this case though it's obviously suboptimal. Personally I'd probably be in favor of dropping that case from std, if there's cases where it's important for people (e.g. interning slices or so) they can likely wrap things in a custom struct.

[ecstatic-morse]

Adding E-easy since the implementation is simple and explained above. We'll want to benchmark the change before merging it, however. I suspect rustc benefits more than most ecosystem crates from this because it interns slices so frequently.

[samrat]

@rustbot claim

[tesuji]

Does rust have const prop for slice?