`copied().min()` performance regression on nightly

[DaniPopes]

Code

I tried this code (godbolt, from this video):

#[no_mangle]
pub fn f(a: &[u16; 8]) -> u16 {
    a.iter().copied().min().unwrap()
}

I expected to see this happen: compiles to vphminposuw x86 instruction (+avx feature)

Instead, this happened: compiles to unrolled cmp + cmov

Note that a manual min loop is unaffected, even with the slice iterator:

#[no_mangle]
pub fn f(a: &[u16; 8]) -> u16 {
    let mut min = u16::MAX;
    for &x in a {
        if x < min {
            min = x;
        }
    }
    min
}

Version it worked on

It most recently worked on: 1.86

Version with regression

rustc --version --verbose:

rustc 1.88.0-nightly (6bc57c6bf 2025-04-22)
binary: rustc
commit-hash: 6bc57c6bf7d0024ad9ea5a2c112f3fc9c383c8a4
commit-date: 2025-04-22
host: x86_64-unknown-linux-gnu
release: 1.88.0-nightly
LLVM version: 20.1.2

@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged

---

searched nightlies: from nightly-2025-02-15 to nightly-2025-04-23
regressed nightly: nightly-2025-04-16
searched commit range: 2da29db...38c560a
regressed commit: 58c2dd9

Weirdly: #139745 cc @thaliaarchi

bisected with cargo-bisect-rustc v0.6.9

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start 1.86.0 -vv --without-cargo --script ./asm.sh 

[thaliaarchi]

Thanks for the bisect. It indeed looks to be caused by my patch. As the linked video indicates, this instruction is limited to min of [u16; 8] and not generalizable. Are there other affected cases?

This case is the oppose of what I was attempting to optimize Copied<T> for—where the iterated data is smaller than a pointer.

For Cloned<T>, perhaps we should specialize on T: TrivialClone (#135634, cc @joboet) to match whatever Copied<T> is changed to do.

[the8472]

Are there other affected cases?

u8, u32, usize no longer vectorize either, probably others too. They just use(ed) different vector instructions.

It's strange that #139745 got merged considering that my similar proposal to elide side-effects in #90209 got rejected.

[joboet]

@rustbot label +I-libs-nominated

I merged #139745 assuming that the precise behaviour around side-effects of the iterator methods was an implementation detail, but that should probably have been discussed beforehand. Also, it was the cause of this performance regression. T-libs, do you want to revert this change?

[Amanieu]

We discussed this in the @rust-lang/libs meeting. We would like #139745 to be reverted for now and re-submitted with a libs-api nomination so that we can properly discuss the exact implications.

I believe the reason this optimizes differently is that before #139745 the compare closure was passed references to copies of the values yielded by the iterator, whereas #139745 changes this to pass the original references yielded by the iterator instead.