distinct non-zst parameters have the same address

[tmiasko]

I would expect the following program to always terminate since the address of a must be distinct from the address of b. Instead, it never terminates when built with -O:

fn main() {
    f([32; 4]);
}

#[inline(never)]
pub fn f(a: [usize; 4]) {
    g(a, a)
}

#[inline(never)]
pub fn g(mut a: [usize; 4], mut b: [usize; 4]) {
    a[0] = 0;
    b[0] = 1;
    assert!(a[0] != b[0]);
    h(a.as_ptr(), b.as_ptr());
}

#[inline(never)]
pub fn h(x: *const usize, y: *const usize) {
    while x == y {}
}

$ rustc +b41634205b549a62cfa55363d1e00c4143d30033 a.rs  && ./a
$ rustc +b41634205b549a62cfa55363d1e00c4143d30033 a.rs -O && ./a
^C

Meta

rustc +b41634205b549a62cfa55363d1e00c4143d30033--version --verbose:

rustc 1.91.0-nightly (b41634205 2025-08-28)
binary: rustc
commit-hash: b41634205b549a62cfa55363d1e00c4143d30033
commit-date: 2025-08-28
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0

[tmiasko]

Minimized. Before:

@a = constant [8 x i8] zeroinitializer, align 1

define void @f() {
  %a = alloca [8 x i8], align 1
  call void @llvm.memcpy.p0.p0.i64(ptr align 1 %a, ptr align 1 @a, i64 8, i1 false)
  call void @g(ptr captures(address) @a, ptr captures(address) %a)
  ret void
}

declare void @g(ptr, ptr) #0

attributes #0 = { memory(none) }

After opt --passes=instcombine:

@a = constant [8 x i8] zeroinitializer, align 1

define void @f() {
  call void @g(ptr nonnull captures(address) @a, ptr nonnull captures(address) @a)
  ret void
}

The condition here seems suspect to me, since it sometimes ignores captures:

https://github.com/llvm/llvm-project/blob/12def78b4df3712b12ef9af388cd5ca7d00742f3/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp#L109-L111

[theemathas]

Smaller rust reproducer:

static X: [usize; 4] = [1, 2, 3, 4];

fn main() {
    let local = X;
    h(&raw const local);
}

#[inline(never)]
pub fn h(ptr: *const [usize; 4]) {
    while &raw const X == ptr {}
}

[apiraino]

(for clarity) the commit indicated in the first comment points to the recent LLVM 21.1.0 merge (#145891)

cc @nikic