Return values from some calls receive unnecessarily separate stack slots due to LLVM optimizer pass

Compiler Explorer reproduction: https://godbolt.org/z/jr5o3sbYx [Disclosure: LLM-minimized repro case]

This is arguably just part of #161506, but this case seems to be caused by a faulty LLVM optimizer pass instead of a MIR one. The CE repro case passes -Zmir-enable-passes=-CopyProp,-GVN,-DestinationPropagation to work around the MIR bug. So, mostly repeating from that bug:

The relevant bit is fn repro, which repeatedly calls a function that has a large output type, and then converts the result to a type that swaps the order of its members (thus requiring a memcpy). The lifetimes of the return values from each call don't overlap, but they end up with separate stack slots anyway, ballooning the stack frame. See the sub rsp, 2840 in the assembly; this frame size increases linearly with each step!(); iteration you add. Appears to be architecture-independent.

This seems to be a bug that occurs in the MemCpyOpt LLVM pass, where llvm.lifetime.[start/end] markers get mistakenly dropped for certain merged temporaries. This LLVM code seems like it might be relevant. Passing -Cllvm-args=-opt-disable=memcpyopt results in a stack frame size that isn't affected by the number of awaits. Demo here: https://godbolt.org/z/5ds89cjrc

This does seem to be size- and alignment-dependent; a 256-byte array doesn't repro, but a 250-byte one does.

Another repro case [also LLM-minimized] that's more similar to the original #161506 one is available here: https://godbolt.org/z/d1zqdnnbx

I can't easily check how far back this repros, since I can only disable specific MIR passes to distinguish these two bugs on nightlies.

Start with the fn repro cases in the linked Compiler Explorer examples and compare the generated stack frame as step!() iterations increase. Read the referenced MemCpyOptimizer.cpp section and inspect the lifetime markers, then compare normal compilation with the listed MIR-pass and memcpyopt workarounds. Done means identifying the LLVM-pass behavior responsible and confirming the frame no longer grows unnecessarily.