Codegen regression in Ipv6Addr [u16; 8] to [u8; 16] conversion

[paolobarbolini]

Code

I tried this code:

// Taken from `Ipv6Addr::new`

pub fn convert1(value: [u16; 8]) -> [u8; 16] {
    let addr16 = [
        value[0].to_be(),
        value[1].to_be(),
        value[2].to_be(),
        value[3].to_be(),
        value[4].to_be(),
        value[5].to_be(),
        value[6].to_be(),
        value[7].to_be(),
    ];
    unsafe { std::mem::transmute::<_, [u8; 16]>(addr16) }
}

pub fn convert2(value: [u16; 8]) -> [u8; 16] {
    let addr16 = value.map(|val| val.to_be());
    unsafe { std::mem::transmute::<_, [u8; 16]>(addr16) }
}

I expected to see this happen: these two pieces of code produced the same assembly

Instead, this happened: the first version generates worse code https://rust.godbolt.org/z/qrz7Pn1a7

Version it worked on

It most recently worked on: 1.76

Version with regression

rustc --version --verbose:

rustc 1.78.0-beta.1 (efd9d2df1 2024-03-18)
binary: rustc
commit-hash: efd9d2df12b5e17fac0b4d0fb89f612ecd79f259
commit-date: 2024-03-18
host: x86_64-unknown-linux-gnu
release: 1.78.0-beta.1
LLVM version: 18.1.2

[dianqk]

The main branch of LLVM may have fixed this issue: https://llvm.godbolt.org/z/WzM1dvrTb.

[workingjubilee]

This seems to become much better if one uses infallible destructuring, like so: https://rust.godbolt.org/z/csraMobE8

Whoops, compared against 1.76, my mistake.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium

[dianqk]

I have bisected to llvm/llvm-project@1e828f8 (llvm/llvm-project#82279). But I'm not sure if this match the backport rules.

I have submitted a backport request, but it may be rejected.

[dianqk]

@rustbot label llvm-fixed-upstream