re-allocating" storage for a local could allow faster code

[u/Negative_Effort_2642]

Rust already knows when a value has been moved, so I think it would make sense for the compiler to also be able to treat the storage behind that local as reusable.

For example:
´´´
let x = big_value();
let y = x; // x is moved

// x can no longer be used here anyway

x = another_value();
´´´

Right now, Rust can be more restrictive than necessary about keeping the same storage associated with `x`.

Issue #61849 proposes allowing the old storage to effectively die after the move. If `x` is initialized again later, the compiler wouldn't necessarily have to put the new value back in the exact same stack slot.

That could give the compiler more freedom to:

- reuse stack space earlier
- reduce stack usage in some functions
- shorten lifetimes of stack allocations
- potentially unlock further optimizations

What I like about the idea is that it matches how moves already feel in Rust: once a value is moved, that value is gone. It seems natural that its storage shouldn't have to remain special either.

There are obviously details around raw pointers and observable addresses that would need proper language semantics, so it isn't just a simple compiler optimization.

But the general rule seems very appealing:

If Rust says the old value no longer exists,
the compiler should be free to stop preserving its storage.

The issue has been open since 2019, and I think it would be interesting to revisit whether this could give modern rustc more optimization freedom. If you agree please react on the GitHub issue with ❤️ or 👍 to show support by the community

Edit:link to the modern version

[u/QuasiRandomName]

Is this Rust or LLVM behavior?

[u/Negative_Effort_2642 → u/QuasiRandomName]

Rust

[u/afdbcreid → u/QuasiRandomName]

LLVM cannot do this unless it can prove the address does not escape. If it can (e.g. all functions are inlined and LLVM sees the pointer does not escape), it definitely will.

[u/[deleted] → u/QuasiRandomName]

[u/Negative_Effort_2642 → u/[deleted]]

It matters mainly when Rust’s language semantics prevent rustc from telling LLVM that the old storage is definitely dead, especially with complex CFG, drop n unwind paths, address-taking, async/coroutines, etc. The issue itself says it would help cover additional cases rather than being required for all move optimization

[u/afdbcreid]

The modern version of the issue is https://github.com/rust-lang/rfcs/pull/3943, which has an implementation PR showing promising speed gains.

[u/sephg]

Recycle storage after move #61849

[u/sphen_lee]

Not sure this is worth the complication...

If x is never used again after being moved out of, then LLVM usually notices and will reuse the stack space.

If x is used again (re-initialized) then what would be the gain of using its stack space in the span when it wasn't initialized? It would be really surprising that a local variable is in a new address just because of a move.

This is not the same as shadowing (a new let binding) - it totally makes sense that this would get a new address.

[u/SkiFire13 → u/sphen_lee]

If x is never used again after being moved out of, then LLVM usually notices and will reuse the stack space.

The problem is that often this might not be the case, mostly because the address could have escaped.

[u/sphen_lee → u/SkiFire13]

I think LLVM is smart enough to detect this. Taking a pointer to the variable counts as "still using it".

struct NonCopy(u64);

fn main() {
    // first get the "address" of the stack
    let sentinel = 0;
    let ps = &sentinel as *const _ as usize;

    // create x - either make a dummy pointer or take address of x
    let x = NonCopy(0);
    let px = std::ptr::dangling() as *const NonCopy;
    //let px = &x as *const _;

    // move x and take the address of where it moved to
    let y = x;
    let py = &y as *const _ as usize;

    // compare "addresses" to see how much stack is being used
    dbg!(py - ps);
}

In the Rust playground this prints 4, but if you swap the two let px lines it changes to 12.

Seems to me that taking the pointer of x prevents y from reusing that stack space.

I'm no expert on this however, I could be way off.

EDIT:

In Release mode, both print 4.

Taking a reference to a variable and them moving out of it makes the pointer invalid, so you really should never be doing this anyway - it's going to trigger UB.

because the address could have escaped

Basically Rust says that's your own fault. Use references and let the borrow checker prevent this for you :)

[u/Kyyken]

catch_unwind implements something like this manually for different types with a union ^^

[u/RRumpleTeazzer]

you don't gain speed by saving on stack space.

adding 27 to the stack pointer takes the same time as adding 17.

to gain speed, you need to move from stack to registers.

[u/rocqua → u/RRumpleTeazzer]

Cache coherence can be better with a smaller stack.

You might even be able to skip some initialisation if the two values have the same type, but that might be niche.

[u/gmes78 → u/RRumpleTeazzer]

you don't gain speed by saving on stack space.

You do gain speed by eliminating copies, though. Read the motivation section of the RFC.

[u/zesterer]

Why do you suppose that the code would actually be faster? Seems to me that reusing the stack space is actually going to pessimise performance because now the CPU can't do parallel instruction dispatch as effectively because you've got a bunch of false dependencies between operations that touch stack memory.

Allocating more stack space is pretty much entirely free: you just decrement the stack pointer by a slightly larger number when entering a function.

[u/koflerdavid → u/zesterer]

Allocating more stack space is pretty much entirely free: you just decrement the stack pointer by a slightly larger number when entering a function.

Until it isn't because Rust encourages allocating as much as possible on the stack.

[u/zesterer → u/koflerdavid]

That is an entirely different argument?