align_to prefix max length not taken into account in optimization

[hsivonen]

I tried this code:

pub fn count_non_ascii_sse2(buffer: &[u8]) -> u64 {
    let mut count = 0;
    let (prefix, simd, suffix) = unsafe { buffer.align_to::<core::arch::x86_64::__m128i>() };
    for &b in prefix {
        if b >= 0x80 {
            count += 1;
        }
    }
    for &s in simd {
        count += unsafe {core::arch::x86_64::_mm_movemask_epi8(s)}.count_ones() as u64;
    }
    for &b in suffix {
        if b >= 0x80 {
            count += 1;
        }
    }
    count
}

Godbolt link

I expected to see this happen: I expected the compiler to conclude that prefix.len() < 16 and, therefore, not emit autovectorization for the first scalar loop.

Instead, this happened: The compiler emitted an autovectorization for the first scalar loop even though the prefix is never long enough for the autovectorization to be useful.

Meta

rustc --version --verbose:

rustc 1.45.0-nightly (a74d1862d 2020-05-14)

[workingjubilee]

Does the equivalent C or C++ code perform this optimization with clang or gcc?

[curiouscat2018]

What about adding assume intrinsic (and math to calculate length) inside buffer.align_to? This solves redundant vectorization according to experiment. It might be difficult to optimize on llvm side.

    let (prefix, simd, suffix) = unsafe { buffer.align_to::<core::arch::x86_64::__m128i>() };
    unsafe {std::intrinsics::assume(prefix.len() < 16);}

https://rust.godbolt.org/z/3ePss8P8Y

[thomcc]

Does the equivalent C or C++ code perform this optimization with clang or gcc?

Yeah, in practice align_to often results in bad codegen because of this. Unfortunately, just adding an assume inside it isn't quite right, because under miri and in other cases it will all end up in the prefix slice.

This is one of the reasons I really dislike the align_to API (IMO it should return an Option in the case where it can't align, rather than putting everything in the prefix).

[thomcc]

(See also my comments in #53020 (comment), although the issue is otherwise unrelated)