[1.; 10] generates worse code than [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]

[jrmuizel]

Here's an example

pub struct L {
    a: [f64; 10],
}

pub struct Allocation<'a, T: 'a> {
    f: &'a mut T,
}

impl<'a, T> Allocation<'a, T> {
    pub fn init(self, value: T) {
        *self.f = value;
    }
}

#[inline(never)]
pub fn foo(a: Allocation<L>) {
    a.init(L {
        a: [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.],
    });
}

#[inline(never)]
pub fn bar(a: Allocation<L>) {
    a.init(L { a: [1.; 10] });
}

gives

.LCPI0_0:
  .quad 4607182418800017408
  .quad 4607182418800017408
example::foo:
  movaps xmm0, xmmword ptr [rip + .LCPI0_0]
  movups xmmword ptr [rdi], xmm0
  movups xmmword ptr [rdi + 16], xmm0
  movups xmmword ptr [rdi + 32], xmm0
  movups xmmword ptr [rdi + 48], xmm0
  movups xmmword ptr [rdi + 64], xmm0
  ret

.LCPI1_0:
  .quad 4607182418800017408
  .quad 4607182418800017408
example::bar:
  sub rsp, 88
  movaps xmm0, xmmword ptr [rip + .LCPI1_0]
  movaps xmmword ptr [rsp], xmm0
  movaps xmmword ptr [rsp + 16], xmm0
  movaps xmmword ptr [rsp + 32], xmm0
  movaps xmmword ptr [rsp + 48], xmm0
  movaps xmmword ptr [rsp + 64], xmm0
  movaps xmm0, xmmword ptr [rsp + 64]
  movups xmmword ptr [rdi + 64], xmm0
  movaps xmm0, xmmword ptr [rsp + 48]
  movups xmmword ptr [rdi + 48], xmm0
  movaps xmm0, xmmword ptr [rsp + 32]
  movups xmmword ptr [rdi + 32], xmm0
  movaps xmm0, xmmword ptr [rsp + 16]
  movups xmmword ptr [rdi + 16], xmm0
  movaps xmm0, xmmword ptr [rsp]
  movups xmmword ptr [rdi], xmm0
  add rsp, 88
  ret

which has an additional copy of the array.

[nagisa]

We generate an explicit loop for all in-line repeat initializers which is why the codegen is usually worse compared to plain literals.

[jrmuizel]

I filed an llvm bug about this: https://bugs.llvm.org/show_bug.cgi?id=40011

[ebkalderon]

Looking at the comment responding to that bug, it seems that it might be an LLVM pass ordering issue. Just curious, but is this something that we can fix or work around on our own fork of LLVM? Or is this a more general issue that will need to be resolved upstream?

[nagisa]

We prefer to have as few differences in our fork from upstream as possible, and what differences we have, must pull their weight to warrant backporting them every time we bump LLVM.

[steveklabnik]

Triage: no change

[jrmuizel]

This appears to be fixed by #81451