Pass by reference "optimization" copies the entire struct on the stack when taking its address. (this didn't happen in stage1)

[IntegratedQuantum]

Zig Version

0.11.0-dev.3910+689f3163a

Steps to Reproduce and Observed Behavior

Here is the test code:

const std = @import("std");

const Struct = struct {
    smallArray: [2]u8 = undefined,
    thisStructIsBig: [65536]u8 = undefined,
    
    pub noinline fn testHiddenPassByReference(x: Struct, index: usize) u8 {
        _ = &x;
        _ = &x;
        _ = &x;
        _ = &x;
        _ = &x;
        _ = &x;
        _ = &x;
        _ = &x;
        _ = &x;
        _ = &x;
        var ptr = &x;
        return ptr.smallArray[index];
    }
};

export fn fun(index: usize) u8 {
    var str = Struct{};
    str.smallArray[index] = 0;
    return str.testHiddenPassByReference(index);
}

Here it is on godbolt: https://godbolt.org/z/7dTneM1od

As you can see in stage2 every single _ = &x creates a copy of x on the stack. (bottom left window in godbolt)
While in simple cases like _ = &x, llvm can optimize it away, the last line var ptr = &x; stays in ReleaseFast(bottom right window in godbolt) and copies the entire struct onto the stack.
Checking with 0.10 and -fstage1(top windows in godbolt) reveals that there is not a single memcpy in stage1

Expected Behavior

This optimization is supposed to reduce the number of times we copy something, not increase it.
If the thing is already passed by reference then taking the reference should effectively be a no-op.

[rohlem]

If the thing is already passed by reference then taking the reference should effectively be a no-op.

Definitely agree.

Note that for safe build modes a stack copy might help implementing stack leak checking (#2646 and, to a lesser extent, #5725) to be as strict as possible regardless of where the passed original argument comes from.
But even if that's the way that is implemented, we should be re-using this one stack copy.

[permutationlock]

I just wanted to point out (maybe this is already known/obvious) that this stack copying seems to occur in all optimization modes and in all cases that &x is referenced on a function parameter x, regardless of type or size. It isn't calling memcpy for small parameters, but new stack copies are made for each reference. The easiest way to observe the behavior is executing the following and seeing that three different addresses are printed.

const std = @import("std");

pub fn printAddr(v: u64) void {
    std.debug.print("{*}\n", .{&v});
    std.debug.print("{*}\n", .{&v});
    std.debug.print("{*}\n", .{&v});
}

pub fn main() void {
    printAddr(12);
}

[slonik-az]

It is crazy. In the example above adding the line std.debug.print("{}\n", .{&v==&v}) to printAddr function prints false. Apparently, &v is not equal to itself. PRO seems to be broken.