Aliasing signed and unsigned integers during optimization

Question

A signed& cannot be initialized from an unsigned& (and vice versa), but strict aliasing rules allow to read/write a signed object through an unsigned& (and vice versa), see C++20 standard [basic.lval]#11.2. This theoretically could be used in compiler optimizations, if the as-if rule is not violated.

Example 1. If I am correct, f could be implemented by just a jump to foo:

void foo(const unsigned& u);

void f(const signed& par)
{
    foo(par);
}

But all compilers load par to a register, store the register on the stack, and pass the stack location to foo. Live demo.

Example 2. Similarly I think g1 and g2 could point to the same memory location:

const signed&   g1 = 1;
const unsigned& g2 = g1;

But compilers tend to allocate two different locations. Live demo.

Question. Why is that? Isn't it a missed opportunity for optimization?

Answer 1

const signed&   g1 = 1;
const unsigned& g2 = g1;

But compilers tend to allocate two different locations.

Here, what is happening is that g1 is converted to a temporary unsigned int and g2 binds to this temporary. And C++ guarantees that different objects have different addresses, thus g1 and g2 need to be stored separately.

Same with your function example. The key point is that having different addresses is an observable behavior. These functions could rely on the fact that their arguments have different addresses because they are references to different objects. If your compiler merged different objects into the same memory space, this observable behavior would change, thus it is not covered under the as-if rule.