rustc fails to perform LICM in simple code

[SludgePhD]

I tried this code:

use std::convert::identity;

#[unsafe(no_mangle)]
pub fn compute(data: &mut [[f32; 2]], scalar: f32) {
    let closure = identity(
        #[inline(never)]
        || {
            //let scalar = scalar;
            for f in data {
                f[0] *= scalar;
                f[1] *= scalar;
            }
        }
    );
    closure();
}

I expected to see this happen: For the baseline x86-64 target, the loop should be vectorized to load, multiply, and store at least 4 floats at a time. If the commented line is uncommented, this does happen and the code processes 8 floats (32 bytes) each iteration:

	movaps	xmm1, xmm0
	shufps	xmm1, xmm0, 0                   # xmm1 = xmm1[0,0],xmm0[0,0]
	xor	r8d, r8d

.LBB1_3:                                # =>This Inner Loop Header: Depth=1
	movups	xmm2, xmmword ptr [rdx + 8*r8]
	movups	xmm3, xmmword ptr [rdx + 8*r8 + 16]
	mulps	xmm2, xmm1
	movups	xmmword ptr [rdx + 8*r8], xmm2
	mulps	xmm3, xmm1
	movups	xmmword ptr [rdx + 8*r8 + 16], xmm3
	add	r8, 4
	cmp	rdi, r8
	jne	.LBB1_3

Instead, this happened: The loop is vectorized (to process 4 elements each iteration), but it reloads scalar from memory every single iteration.

.LBB1_4:                                # =>This Inner Loop Header: Depth=1
	movups	xmm0, xmmword ptr [rdx + 8*r9]
	movss	xmm1, dword ptr [rax]           # xmm1 = mem[0],zero,zero,zero
	shufps	xmm1, xmm1, 0                   # xmm1 = xmm1[0,0,0,0]
	mulps	xmm1, xmm0
	movups	xmmword ptr [rdx + 8*r9], xmm1
	add	r9, 2
	cmp	r8, r9
	jne	.LBB1_4

xmm1 is reloaded from [rax] every iteration, even though rax is not modified inside the loop.

This problem appears to be a combination of

• Processing elements of type [f32; 2] in the loop (f32 does not reproduce the problem; this example was reduced from a linear algebra library where the element type is Vec2f)
• Doing so inside a closure that loads scalar from its environment (making the closure take data and scalar as arguments does not reproduce the problem).

llvm-mca estimates a throughput (on Skylake) of 1.63 IPC for the bad version, and 2.13 IPC for the good version (and the good version processes twice the elements per iteration).

Meta

Reproduces on the playground, with stable 1.89.0 and nightly 2025-08-09.

[nikic]

Godbolt: https://rust.godbolt.org/z/jeecdx8nb

It looks like Rust captures all the closure variables via references, so that f32 becomes an &f32 stored in the closure score, which makes it impossible to determine that it does not alias anything else.

(This is of course what we want semantically, but it would make sense to capture small Copy values that do not have their address taken by value instead.)

[SludgePhD]

f32 does not contain an UnsafeCell, so Rust should have all the information it needs to perform the optimization (But maybe LLVM has no way to convey this aliasing information? It may be limited to expressing C-style restrict* arguments)

However, this does not explain why the optimization does happen when the element type of the slice is f32 instead of [f32; 2].

[nikic]

@SludgePhD Ah yes, that's a good point. I didn't notice that LLVM actually inserts a runtime check here that makes sure that the load does not alias the stores. This loop versioning typically inserts noalias metadata to enable LICM. And this does happen for the f32 case. I'm not sure why the necessary metadata is not present in the [f32; 2] case.

[nikic]

Upstream issue: llvm/llvm-project#153006

Not storing the pointer in the closure scope would be much better though, because there would be no need to generate a runtime check in the first place.

[SludgePhD]

Thanks for filing!