`MaybeUninit::uninit` zero initializes large uninit array besides small other field

[steffahn]

The code is slightly minimized from this forum thread.

use std::mem::MaybeUninit;

#[derive(Debug)]
pub struct Stack<T, const CAP: usize> {
    len: usize,
    v: MaybeUninit<[T; CAP]>,
}

impl<T, const CAP: usize> Stack<T, CAP> {
    /// Create a new empty `Stack`.
    pub fn new() -> Self {

        Stack {
            len: 0,
            v: MaybeUninit::uninit(),
        }
    }
}

type MyStack = Stack<i32,1000>;

pub struct C {
    a: MyStack,
    b: MyStack,
}

impl C {
    #[inline(never)]
    pub fn new() -> C
    {
        C { a:MyStack::new(), b:MyStack::new() }
    }
}

This produces a large memset since 1.93

example::C::new::h966d6519f96c8d05:
        push    rbx
        mov     rbx, rdi
        mov     edx, 8016
        xor     esi, esi
        call    qword ptr [rip + memset@GOTPCREL]
        mov     rax, rbx
        pop     rbx
        ret

previously (1.92) the asm was much more reasonable:

example::C::new::hb6aa5d89c35231d2:
        mov     rax, rdi
        mov     qword ptr [rdi + 4000], 0
        mov     qword ptr [rdi + 8008], 0
        ret

(same comparison on Compiler Explorer)

---

Bisection points to:

• Fix MaybeUninit codegen using GVN #147827

[scottmcm]

The memset comes from LLVM's MemCpyOptPass: https://rust.godbolt.org/z/46bjEn446

Note that in the MIR https://rust.godbolt.org/z/TEnas3Ene it's

    bb0: {
        StorageLive(_2);
        _3 = Stack::<i32, 1000> { len: const 0_usize, v: const <uninit> };
        _2 = C { a: copy _3, b: copy _3 };
        _5 = &mut _2;
        _4 = dosomething(move _5, move _1) -> [return: bb1, unwind continue];
    }

which is good work from GVN to emphasize that <uninit>, and probably can't get materially better at the MIR level.

So a fix would need to be something smarter in LLVM (to do something better with that memcpy) or in rustc's codegen backend (to emit those two copy _3s in a different way).

[nikic]

IR test case: https://llvm.godbolt.org/z/xosG1Eadd

Yeah, MemCpyOpt should not be replacing undef with zero in cases like this where it makes the memset much larger.

[saethlin]

This looks like a slightly more convoluted form of #138625, which I believe root-causes to the same MemCpyOpt issue. We were just able to paper over it for simple cases 🙃