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

[scottmcm]

I think I unknowingly investigated this in #107634

AFAICT, here's what's happening:

• For large types, the ABI for returning a value is (today) that the caller passes in a pointer to enough space for the callee to write the data into it.
• However, Option<T> is (usually) larger than T, so the space provided by a caller to a -> T function is not enough for Option<T>.
• Thus if a -> T function calls a -> Option<T> function, it needs to allocate enough space on its own stack for the Option<T>, and pass a pointer to that
• This means that there's an extra memcpy out of the Option<T> on the stack to the out T pointer, in something like return gives_option().unwrap().

And LLVM can't optimize it out because of the size difference (and the layouts don't match either, so it'd still need a memmove even if it could skip the stack allocation).