Recycle storage after move

[tmandry]

We should experiment with "re-allocating" storage for a local after it's moved from if it gets re-initialized. This would enable more optimizations, but could have some potential fallout.

EDIT: See this comment for further explanation of what kinds of optimizations this would enable.

Quoth @RalfJung, from #59123 (comment):

Currently, the following (entirely safe) code will definitely return true:

let mut x = String::new();
let addr_x = &x as *const _ as usize;
drop(x);
// later
x = String::new();
let addr_x2 = &x as *const _ as usize;
return addr_x == addr_x2;

If we want to do optimizations like yours here (and I am totally sympathetic to that), we have to explain in the "Rust Abstract Machine" (and in Miri) why this program might return false. And the answer cannot be "there is UB", because this is safe code.

This is a topic that @nikomatsakis, @eddyb and me have touched on several times already, without ever hashing out a full plan. But in the current state of affairs, the only mechanism we have to "defeat" pointer equality tests like the above is to make sure that this is not the same allocation any more.

So, one thing we might do is to do StorageDead(x); StorageLive(x); immediately after every move. This "re-allocates" x and thus definitely kills any existing pointers and also "defeats" pointer comparisons. The immediate StorageLive is to keep the liveness state in sync in both branches of a conditional (which might or might not be relevant -- unfortunately LLVM's semantics for these intrinsics is less than clear). I guess the StorageLive could be moved down in cases where there is no merging control flow, which should give you your optimization in many cases.

It is possible to do a subset of the optimization discussed in #59123 without this, but this would help cover more cases, in this optimization and others.

cc @cramertj @eddyb @nikomatsakis @RalfJung

[eddyb]

There's further discussion in #59123 (comment), I wish we could just fork the thread.

[RalfJung]

@eddyb writes

No, I was referring to the case where we want the semantics of Operand::Move to be that they invalidate any outstanding borrows, similar to Storage{Dead,Live} but without bloating the MIR/impacting analyses which rely on some sort of dominance relationship.

I don't understand your position now. Are you saying you don't mind if source-level moves invalidate borrows, you just don't want it be be encoded into Operand in MIR, but rather something more like StorageDead? That would make sense, I just kept thinking you were worried about source-level moves.

Yes, I'd find it rather strange to have this encoded in the Operand. It would also be non-uniform as Operand does not have to be a local. I could live with encoding basically the same thing in something more like StorageDead. That's explicit and easy to give semantics.

Perhaps surprisingly, I have much less strong opinions about surface language semantics than about MIR semantics.^^ We'd still want to make sure of course to make that translation not too weird -- magic UB-inducing MIR instructions like StorageDead or Retag should be inserted in a predictable way.

[eddyb]

Right, the confusing thing was that all along I've assumed you were against unsafe code not being able to reinitialize indirectly (i.e. through a raw pointer) some local that had been moved out of.

I consider the MIR more flexible and even its "place-oriented non-SSA CFG" nature to be subject to change, whereas the surface-level semantics to be the important thing to discuss, UB-wise.

In the short term, to keep things simple, I wouldn't mind a StorageRefresh (name up for bikeshed) after each Operand::Move, that has the effects of a Storage{Dead,Live} pair but doesn't risk breaking certain kinds of analysis (which can just ignore it if they want to remain conservative).

Long-term, if we go in this direction, I would expect us to be shrinking storage ranges, although I'm not sure what to do about the simple notion that a StorageLive dominates all uses - it's almost as if "storage-live" is becoming very close to (or even replaceable with) "(partially) initialized".

[RalfJung]

Right, the confusing thing was that all along I've assumed you were against unsafe code not being able to reinitialize indirectly (i.e. through a raw pointer) some local that had been moved out of.

Oh I see. No I am not necessarily opposed to forbid unsafe code from doing that. I just think the way we forbid it should be as clean and principled as we can make it.

I consider the MIR more flexible and even its "place-oriented non-SSA CFG" nature to be subject to change, whereas the surface-level semantics to be the important thing to discuss, UB-wise.

That's fair. On the other hand, I think surface language semantics of a language as complex as Rust is best explained by elaboration into some simpler language. And I think an idealized version of MIR is a reasonable candidate for the target language of this elaboration.

[tmandry]

To further elaborate on the kinds of optimizations we could do with this..

If a local x is moved from, but

• Has only had its address taken using &x
• Is Freeze (does not contain interior mutability)

Then we could optimize away its storage after it's moved from. Rust will enforce that any borrow is dead after the move, of course, and transmuting *const to *mut is already considered UB. So in order to do this type of optimization soundly, we must declare that

• accessing the old address of x after it is moved is UB
• the address of x may change after it is re-initialized

[RalfJung]

1. accessing the old address of x after it is moved is UB
2. the address of x may change after it is re-initialized

(1) follows from (2). But my concern is that we should specify (2) in an operational way -- that is, we can't just say "the address may change", we have to describe the operational behavior that causes it to change. Something like StorageDead+StorageLive. Something that can be implemented in Miri or similar checkers.