What are our guarantees regarding pointer identity on `const`s

[chorman0773]

We don't currently guarantee that pub const FOO: &'static u32 = &0; has a stable address (same with string literals). This has had some suprising results in the past (I cannot find the miri issue I was looking for). What, if anything, do we want to guarantee with respect to this (and code like pub const FOO: *const u32 = &0 as *const u32;)

[RalfJung]

This is not just for promoteds, this is generally about addresses of constants.

[RalfJung]

This is also tracked in #239 (not sure how fine-grained we want to go with issues here)

[chorman0773]

I'd say specifically when that address goes into another const. It's fairly obvious to me that writing &0 multiple times can yield different addresses. The question is whether, after shoving that reference into another const (or casting to a pointer and shoving said pointer into a const), do we guarantee that the value of that const is stable.

…

On Wed, May 24, 2023 at 04:17 Ralf Jung ***@***.***> wrote: This is not just for promoteds, this is generally about addresses of constants. — Reply to this email directly, view it on GitHub <#406 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGLD223IXKGKMXXRA4PJBLXHW7YXANCNFSM6AAAAAAYMPWGS4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[chorman0773]

FWIW, lccc's abi gives an external name to the address of a constant iff it is part of the initializer of a const, which gives it a stable and unique address (except cross FLT, when a generic const is involved b/c windows).

[bjorn3]

cg_clif intentionally duplicates anonymous const allocations between mono items (functions, statics, global asm) to allow codegening every mono item independently even within a single cgu. For non-generic consts it did be possible to give them a unique name and treat them as separate mono items, but requiring that generic consts have to be deduplicated has the same issues as for generic statics.

[chorman0773]

Indeed so likely they'd be excluded. Though, absent dynamic libraries (A final link target is defined as either a binary or a dylib/cdylib) is there a problem with emitting a linkonce group and deduplicating at link time? I guess other than the added complexity if cranelift doesn't already support COMDATs.

…

On Wed, May 24, 2023 at 07:44 bjorn3 ***@***.***> wrote: cg_clif intentionally duplicates anonymous const allocations between mono items (functions, statics, global asm) to allow codegening every mono item independently even within a single cgu. For non-generic consts it did be possible to give them a unique name and treat them as separate mono items, but requiring that generic consts have to be deduplicated has the same issues as for generic statics. — Reply to this email directly, view it on GitHub <#406 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGLD26A445XCCT2R373KHLXHXYA3ANCNFSM6AAAAAAYMPWGS4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bjorn3]

What would the symbol name of the linkonce group be? Rust currently doesn't expose any stable id for anonymous allocations. It only has an AllocId which is different across multiple compiler sessions. For statics tcx.global_alloc(alloc_id) returns a DefId, but for anonymous allocations it directly returns the allocation data itself. If this fixed, it should be quite easy to implement by handling it like a static with a mono item and fixed symbol name, even without linkonce.

[chorman0773]

Unfortunately, I am not privy to the internals of rustc. I would expect that to be a necessary fix for all codegens, though, not just cranelift. The linkonce would be for generic constants (associated constants of generic impl blocks), to have a single address for the entire binary/dylib/cdylib - this would primarily be a QoI thing, though, as thanks to windows, it isn't possible to guarantee a single address in the presence of dynamic linking.

…

On Wed, 24 May 2023 at 10:45, bjorn3 ***@***.***> wrote: What would the symbol name of the linkonce group be? Rust currently doesn't expose any stable id for anonymous allocations. It only has an AllocId which is different across multiple compiler sessions. For statics tcx.global_alloc(alloc_id) returns a DefId, but for anonymous allocations it directly returns the allocation data itself. If this fixed, it should be quite easy to implement by handling it like a static with a mono item and fixed symbol name, even without linkonce. — Reply to this email directly, view it on GitHub <#406 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGLD24U6GBWHY7NIEDOWEDXHYNHVANCNFSM6AAAAAAYMPWGS4> . You are receiving this because you authored the thread.Message ID: ***@***.***>