Figure out the interaction of GVN and function/vtable pointers about rust HOT 8 OPEN

unnamed_addr allows LLVM to merge multiple functions if they have the same body after optimizations. This will result in their address comparing equal.

from rust.

So there's no impact on icmp semantics?

Apart from unnamed_addr we also have our own multiple-codegen-unit issue, where the same function can have more than one address. That could be considered as making a choice at fn-item-to-fn-ptr coercion time. The possible concern here is having the AllocId we generate there move into different codegen units or crates so they don't end up being the same address. But that's already the case I think? const C: fn() = myfunc; is evaluated once but we just use the AllocId everywhere and each crate will do with that whatever it wants. Even without GVN I think this means that that const can have different integer values in different crates?

from rust.

Cc @oli-obk for the last question

from rust.

So there's no impact on icmp semantics?

The icmp may evaluate to either true or false, but it will do so consistently. That is, for unnamed_addr symbols, LLVM will not fold "icmp eq s1, s2" to false in cases it normally could, in case s1 and s2 end up being merged later.

from rust.

const C: fn() = myfunc; is evaluated once

it is evaluated per-crate. For constants we only cache within the current crate.

but we just use the AllocId everywhere and each crate will do with that whatever it wants.

yea, that's why it doesn't matter, each crate generates its own AllocId per function pointer anyway. And we do generate multiple different AllocIds for the same function pointer... sometimes. See

Even without GVN I think this means that that const can have different integer values in different crates?

what integer values?

from rust.

@nikic thanks!

@oli-obk

yea, that's why it doesn't matter, each crate generates its own AllocId per function pointer anyway.

If we have const C: fn() = myfunc; in one crate then that's a single AllocId, right?

But OTOH AllocId is a per-rustc-invocation identifier and they get re-assigned when rlibs get loaded... right? So the question is somewhat moot anyway.

what integer values?

The underlying address, after compilation.

So probably the GVN issue is about something like

const C: fn() = myfunc;

let x = C;
let y = x; // definitely the same address as x

becoming

const C: fn() = myfunc;

let x = C;
let y = C; // maybe a different address than x?

I think we want to be sure that C is the same address when it is used multiple times in the same function. But what has to happen to make that true?

from rust.

But what has to happen to make that true?

It's already true if LLVM makes it true. We swap the alloc id for its Instance in codegen. So whatever happens there is relevant.

To also deduplicate AllocIds, we need to remove

from rust.