Vec::pop() sometimes returns value inefficiently.

[human-0]

I tried this code:

#[repr(align(32))]
#[derive(Copy, Clone)]
pub struct Data {
    u64s: [u64; 4],
    options: Option<(u64, u8, Option<u8>)>
}

pub fn len_minus_one(mut vec: Vec<Data>, value: &mut Data) {
   *value = vec[vec.len() - 1];
   vec.pop();
}

pub fn pop(mut vec: Vec<Data>, value: &mut Data) {
   *value = vec.pop().unwrap();
}

I expected to see this happen: The two functions generate similar assembly.

Instead, this happened: Vec::pop() uses far less efficient copying.

Meta

rustc --version --verbose:

<version>
binary: rustc
commit-hash: 88f19c6dab716c6281af7602e30f413e809c5974
commit-date: 2021-05-03
host: x86_64-pc-windows-msvc
release: 1.52.0
LLVM version: 12.0.0

It also happens on Nightly, although the generated assembly is much better.

Edit: It appears to be related to an Option holding the value, because the same behaviour is observed when using vec.get(vec.len() - 1).copied().unwrap() but not *vec.get(vec.len() - 1).unwrap().
Playground Link

[human-0]

It seems that it is not specific to Vec::pop(), but Option in general. It even occurs with just *value = Some(data).unwrap();.

Playground Link

[nikic]

@human-0 Those playground links are the same :)

[human-0]

Fixed.

[scottmcm]

@Moxinilian this seems like an issue that the match optimization you're working on in #85133 could potentially be able to help with (after MIR inlining), if you're looking for more test cases.

Here's another simple place where the mir-opt would be nice (though LLVM already handles it fine): https://rust.godbolt.org/z/oevPf6d6h

[scottmcm]

@human-0 Did you really mean mut vec: Vec<Data> here? I would have expected vec: &mut Vec<Data>, which means the function isn't dropping the Vec any more and thus there's way less stuff generated.

There's still a small difference between the two, though: https://rust.godbolt.org/z/M7v1PMjfv