Add Rvalue-static-promotion RFC

[Kimundi]

Promote constexpr rvalues to values in static memory instead of stack slots, and expose those in the language by being able to directly create 'static references to them.

This would allow code like let x: &'static u32 = &42 to work.

Rendered

Credit for idea and impl goes to @nikomatsakis and @eddyb ;)

Closes #827

[sfackler]

This would I believe actually be a bit more powerful than the current workaround with consts and statics since those can't be parameterized over type parameters of the e.g. function they're defined in.

[Kimundi]

Hm, indeed, you can do stuff like &None::<T> with this.

[eddyb]

For example, &None::<T> could be returned even if T were a type parameter, or &[T; 0] (but the array case is actually hardcoded from before any attempts at rvalue promotions).

[eddyb]

In the MIR, rvalues end up in temporary "lvalues" (as opposed to variable lvalues).
So when we make promotion-to-'static work for the MIR, we can even promote variables, too, if they're eligible (truly immutable, no UnsafeCell).

[petrochenkov]

The restriction about not having a destructor should probably stay even for zero-sized types.

[eddyb]

Currently types with destructors are not zero-sized but that will change and I agree - there is no reason not to be conservative, for now, IMHO.

For the specific case of destructors, remember that the following are more or less equal:

let x = &EmptyDestructible;
...

let temp = EmptyDestructible;
{
    let x = &temp;
    ...
}
Drop::drop(&mut temp)

Thus, rvalue drops can be considered "mutable accesses".
And even if the destructor doesn't have any bytes to actually mutate, it has to run.
So you would be changing behavior if you remove the destructor call, and otherwise you kind of make a mess out of borrow semantics by allowing the resulting &'static EmptyDestructible to escape the scope its destructor ran in.

In the end, no UB can actually occur, but it still seems troubling to do this dance around destructors.

[arielb1]

We want to use value-destructor-freedom rather than type-destructor-freedom here.

[steveklabnik]

I am concerned about this being breaking behavior; I'm not sure what would cause it, exactly, but &42 being a pointer to the stack is at least well-documented behavior.

[petrochenkov]

Consider this function:

fn f() -> *const i32 {
   let a = &10;
   a
}

What type does a have? &'static i32?
Is pointer returned by f valid?
Now consider another function:

fn f() {
   let a = &10;
   use_pure(a);
}

The pointer to 10 doesn't escape from f. Does 10 still have to be kept in static memory or it may be optimized (placed into a code instruction as immediate value, for example)? Does LLVM perform this escape analysis and optimization automatically or Rust front-end will have to do something for it to happen?

[eddyb]

@steveklabnik AFAIK no stable (1.x) Rust version has been released where &42 points at the stack: the implementation of rvalue promotion has been around since January or so.
So if there is any documentation claiming references of rvalues always point at the stack, that documentation is outdated and wrong.

[steveklabnik]

I cannot find what I'm thinking of now, but I remember having arguments related to this issue on the bugtracker at some point.

[eddyb]

@petrochenkov In the existing (1.x stable and current nightly) compilers, &10 always points at .rodata, no matter what.

It goes deeper than that: let x = constexpr; lowers to effectively let x = *&constexpr;.
There are two exceptions: immediates are loaded directly by rustc_trans (allowing LLVM to remove the global holding the constant) and [constexpr; n] are instantiated in-place because that's more efficient than copying the whole array from .rodata.
This is not unlike what clang does for struct literals.

I assume your performance concerns are about the following scenarios (represented in pseudo-machine-code):

*stack = 10
arg0 = stack
call use_pure

arg0 = rodata_ptr_to_10
call use_pure

You are correct that in variable-length encodings, storing a byte to memory and doing a register-to-register copy can be shorter than placing a constant pointer into a register.

But is it faster? Even if the stack is in cache (which it should be), the memory store is not free.
OTOH, rodata_ptr_to_10 may not be in cache, causing a penalty on the first access.

AFAIK LLVM doesn't do that kind of escape analysis at this moment.
Or if it does, I haven't seen it demote globals to allocas.

[petrochenkov]

@eddyb
Interesting, thanks.
It looks like LLVM indeed does the optimization. In this example the constant A presents in unoptimized IR but is inlined in optimized IR.

[eddyb]

@petrochenkov That's because you're loading the value and not actually using the pointer itself.

[petrochenkov]

@eddyb
I actually meant this case. If the pointer itself is used then it probably doesn't matter much where it points to (LLVM keeps it in rodata).

[glaebhoerl]

Isn't "promoting to &'static mut T is OK if sizeof(T) = 0" just a special case of "&mut T: Copy is OK if sizeof(T) = 0"? It seems like the same reasoning - you can't violate memory safety if you never follow the pointer, no matter how many "aliases" exist - applies. That said, I wonder if there's user code which relies on the fact that &mut T is never Copy, regardless of T, to enforce some extra-lingual invariants? Does that (potentially) make any sense?

(This also feels eerily similar to "overlapping impls of trait Tr are OK if members(Tr) = 0"... I wonder if there's some deeper connection here.)

[nikomatsakis]

On Fri, Dec 18, 2015 at 03:02:03PM -0800, Eduard-Mihai Burtescu wrote:

@petrochenkov In the existing (1.x stable and current nightly) compilers, &10 always points at .rodata, no matter what.

It seems to me that the purpose of this RFC (and i've not had time to
read it yet...) is basically to expand (and perhaps define more
precisely) the set of expressions where you can safely rely on values
being moved into static slots, right?

[nikomatsakis]

On Sat, Dec 19, 2015 at 06:06:14AM -0800, Gábor Lehel wrote:

Isn't "&'static mut T is OK if sizeof(T) = 0" just a special case of "&mut T: Copy is OK if sizeof(T) = 0"? It seems like the same reasoning - you can't violate memory safety if you never follow the pointer, no matter how many "aliases" exist - applies. That said, I wonder if there's user code which relies on the fact that &mut T is never Copy, regardless of T, to enforce some extra-lingual invariants? Does that (potentially) make any sense?

Indeed, this kind of special-case reasoning around zero-sized types
makes me sort of uncomfortable. I feel like it's something one is
likely to forget about when reasoning "in the abstract".

[eddyb]

@nikomatsakis My point is that there won't be any surprise because the compiler already does this promotion so unsafe code couldn't have relied on &10 to ever point to the stack, unless it was from before 1.0.

[nikomatsakis]

On Tue, Dec 22, 2015 at 09:09:40AM -0800, Eduard-Mihai Burtescu wrote:

@nikomatsakis My point is that there won't be any surprise because the compiler already does this promotion so unsafe code couldn't have relied on &10 to ever point to the stack, unless it was from before 1.0.

Sure, though conceivably it might rely on [22;22] being on the
stack. But in general it seems like we should clarify a range of
expressions where we MAY promote to a static if we so choose, and a
set where we WILL promote. The latter are the set where you can have
lifetime 'static. The former are an optimization.

[eddyb]

You're referring to the same thing as my previous comment, right?

Something along the lines of:

let value = 5;
do_something_with(&value); // fine even if promoted
unsafe {
    // happens to work now, page fault if promoted
    *transmute::<&i32, &mut i32>(&value) = 6;
}

[eddyb]

FWIW, in two (1 and 2) places in trans::expr, #1229 resulted in doing the wrong thing when debug assertions are turned off (i.e. Release mode): &(255_u8 + 1) will compile with a warning and point to the stack, instead of .rodata, as it otherwise would (if it wasn't overflowing).
This has to be fixed before rvalue promotion is turned on.

[sfackler]

What is the status of this?

[nikomatsakis]

cc @rust-lang/lang -- I'd like to see this RFC go forward! Most of the infrastructure in the compiler is laid, and I think the core idea is sound. The key is that when you borrow a constant (e.g., &42) that meets the criteria in the RFC, this will be allocated into static memory, and hence we can assign a &'static 42 lifetime. This eliminates annoying (and unnecessary) errors in practice and also rationalizes some of our other typing rules (e.g., &[] has type &'static [T] for some T).

Reading the thread, I think the major concerns have to do with the runtime guarantees. Since the runtime behavior does not (and should not) depend on lifetime inference, this implies that &42 is guaranteed to be in static memory. You can imagine safe code relying on this. That said, this ought not to be a breaking change -- for optimization reasons, this is largely true today in any case, so it's not really a breaking change -- we just use conservative typing rules. But also, this seems to come back to the unsafe code guidelines as well. =)

That said, I still haven't had time to do a detailed review of the rules -- I have the printout here in front of me though and plan to do it now. But my feeling is that while we may find some minor detail to correct, we should go forward with the general idea.

@rfcbot fcp merge

[nikomatsakis]

Ah, one thought I had that I should raise. This text in the RFC itself:

This workaround also has the limitation of not being able to refer to type parameters of a containing generic functions, eg you can't do this:

fn generic<T>() -> &'static Option<T> {
    const X: &'static Option<T> = &None::<T>;
    X
}

Seems to suggest we ought to also just enable generic statics/constants already. I used to think "that makes no sense!" -- at least for statics -- but now I realize it's just another case of monomorphization of course. That said, it's prob better to defer this to a second RFC.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

• @aturon
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix

Concerns:

• basis-for-static-mut resolved by Add Rvalue-static-promotion RFC #1414 (comment)

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[pnkfelix]

Is this signature a typo? In particular, did you mean to write that the return value is a &mut FnMut(u32, u32) -> u32 ?

[Kimundi]

Indeed, that's a typo!

[pnkfelix]

rfcbot concern I am a little uneasy about the basis for supporting &'static mut of a zero-sized type. Maybe I just am not understanding the expected use case.

(update: sorry for repeating myself; I'm still trying to figure out how to use the rfcbot...; I put a properly constructed comment down below.)

[eddyb]

@pnkfelix I agree, in fact, the way it's implemented right now we don't take advantage of it in most cases.
However, do keep in mind &mut [] is already 'static and would remain a special-case.

[eddyb]

@rfcbot resolved basis-for-static-mut

(@dikaiosune does this work yet?)

[aturon]

@eddyb I think only the original comment author can resolve their concern.

[pnkfelix]

@rfcbot resolved basis-for-static-mut

[pnkfelix]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[nrc]

This has been in FCP for 16 days and there have been no new comments. Merging.

[briansmith]

Does the UnsafeCell stuff also need to be done for atomic types, since they seem to have the same issues?

[sfackler]

AtomicFoo is already built around UnsafeCell: https://doc.rust-lang.org/src/core/sync/atomic.rs.html#91-93

[eddyb]

Atomic types use UnsafeCell inside, there is no other sound way.