问题

我的直觉对于移动和复制可能是错误的。我期望Rust编译器会将对不可变值的移动优化为无操作。由于该值是不可变的，在移动后我们可以安全地重用它。但是在Rust 1.65.0 on Godbolt上编译的汇编代码将该值复制到内存中的新位置。我正在研究的Rust代码：

pub fn f_int() {
    let x = 3;
    let y = x;
    println!("{}, {}", x, y);
}

使用-C opt-level=3选项得到的汇编代码：

    ; pub fn f_int() {
    sub     rsp, 88
    ; let x = 3;
    mov     dword ptr [rsp], 3
    ; let y = x;
    mov     dword ptr [rsp + 4], 3
    mov     rax, rsp
    ...

为什么let y = x;会导致mov dword ptr [rsp + 4], 3和mov rax, rsp？为什么编译器在汇编中没有将y视为与x相同的变量？

（这个问题看起来类似，但它涉及到了不可复制的字符串。我的问题是关于可复制的整数。看起来我描述的情况不是一个被忽视的优化机会，而是我理解上的一个基本错误。）

pub fn f_int() {
    let x = 3;
    let y = x;
    println!("{}, {}", x, y);
}

    ; pub fn f_int() {
    sub     rsp, 88
    ; let x = 3;
    mov     dword ptr [rsp], 3
    ; let y = x;
    mov     dword ptr [rsp + 4], 3
    mov     rax, rsp
    ...

答案1

得分: 4

如果你将示例更改如下
```rust
pub fn f_int() -> i32 {
    let x = 3;
    let y = x;
    // println!("{}, {}", x, y);
    x+y
}

优化会发生

example::f_int:
        mov     eax, 6
        ret

println!() 宏（以及write!()...）会对其参数取引用，并使用这些引用提供给格式化机制。
可能，编译器推断出为一些（没有内联）的函数提供引用需要将数据存储在内存中以获得地址。
因为类型是Copy，语义意味着我们有两个不同的存储，否则，共享存储将会是对于一个移动操作的优化（而不是复制）。

<details>
<summary>英文:</summary>

If you change your example like this
```rust
pub fn f_int() -&gt; i32 {
    let x = 3;
    let y = x;
    // println!(&quot;{}, {}&quot;, x, y);
    x+y
}

the optimisation takes place

example::f_int:
        mov     eax, 6
        ret

The println!() macro (as well as write!()...) takes references on its parameters and provides the formatting machinery with these references.
Probably, the compiler deduces that providing some functions (that are not inlined) with references requires the data being stored somewhere in memory in order to have an address.
Because the type is Copy, the semantics implies that we have two distinct storages, otherwise, sharing the storage would have been an optimisation for a move operation (not a copy).

答案2

得分: 4

I would not call it a fundamental mistake in your understanding, but there are some interesting observations here.

First, println!() (and the formatting machinery in particular) is surprisingly hard to optimize, due to its design. So the fact that with println!() it was not optimized is not surprising.

Second, it is generally not obvious it is OK to perform this optimization, because it observably make the addresses equivalent. And println!() takes the address of the printed values (and passes them to an opaque function). In fact, Copy types are harder to justify than non-Copy types in that regard, because with Copy types the original variable may still be used after a move while with non-Copy types it is possible that not.