inefficient passing of `nullptr` to parameter of type `nullptr_t`

[zygoloid]

void f(decltype(nullptr) x);
void g() { f(nullptr); }

Clang (and GCC) generate an instruction to zero a register when making this call. That's unnecessary -- nullptr_t contains only padding bits, so there is no need to put any particular value in the parameter.

It's a little weird that the C++ standard requires it to have the same size and alignment as a pointer, but also says that lvalue-to-rvalue conversions don't touch memory. And it's unfortunate that our ABIs require a register to be allocated to (not) passing it. But it's too late to change any of that.

We also have divergence from GCC on this:

void h() {
  volatile auto p = nullptr;
  p = nullptr;
  p = p;
}

Clang generates three volatile stores of ptr null here and zero volatile loads. GCC generates three volatile stores and one volatile load. To my reading, Clang is right and GCC is wrong: the standard is clear that there is no read from memory in this case, but each assignment does constitute a modification -- but we don't need to store null in particular, any bits would do here, so long as we perform a store. (Weirdly.)

I think instead of producing ptr null when lowering a nullptr expression, we should instead produce ptr poison, given that the representation comprises only padding bits.

[llvmbot]

@llvm/issue-subscribers-c-1

Author: Richard Smith (zygoloid)

```c++ void f(decltype(nullptr) x); void g() { f(nullptr); } ```

Clang (and GCC) generate an instruction to zero a register when making this call. That's unnecessary -- nullptr_t contains only padding bits, so there is no need to put any particular value in the parameter.

It's a little weird that the C++ standard requires it to have the same size and alignment as a pointer, but also says that lvalue-to-rvalue conversions don't touch memory. And it's unfortunate that our ABIs require a register to be allocated to (not) passing it. But it's too late to change any of that.

We also have divergence from GCC on this:

void h() {
  volatile auto p = nullptr;
  p = nullptr;
  p = p;
}

Clang generates three volatile stores of ptr null here and zero volatile loads. GCC generates three volatile stores and one volatile load. To my reading, Clang is right and GCC is wrong: the standard [is clear](https://eel.is/c++draft/conv.lval#3.1) that there is no read from memory in this case, but each assignment [does constitute a modification](https://eel.is/c++draft/expr.assign#2) -- but we don't need to store null in particular, any bits would do here, so long as we perform a store. (Weirdly.)

I think instead of producing ptr null when lowering a nullptr expression, we should instead produce ptr poison, given that the representation comprises only padding bits.

[efriedma-quic]

The C standard actually does specify that nullptr_t is a null pointer. And there are situations where it's relevant; for example, for va_arg allows the case where "the type of the next argument is nullptr_t and type is a pointer type that has the same representation and alignment requirements as a pointer to a character type".

[zygoloid]

The C standard actually does specify that nullptr_t is a null pointer. And there are situations where it's relevant; for example, for va_arg allows the case where "the type of the next argument is nullptr_t and type is a pointer type that has the same representation and alignment requirements as a pointer to a character type".

C++ handles this in the default argument promotions: An argument that has type cv std​::​nullptr_t is converted to type void* ([conv.ptr]). So the next argument is never of type nullptr_t in C++. Hopefully C didn't lose that, but if it did, we can presumably apply the C++ rule in C.

[zygoloid]

Ah, looks like C doesn't allow this optimization; their nullptr_t has an object representation that matches the object representation of (void*)0, rather than following C++ and having no mandated non-padding bits. So this optimization would be C++-only, and C requires that we actually store a null pointer representation into objects of type nullptr_t. That's a shame.

[AaronBallman]

Ah, looks like C doesn't allow this optimization; their nullptr_t has an object representation that matches the object representation of (void*)0, rather than following C++ and having no mandated non-padding bits. So this optimization would be C++-only, and C requires that we actually store a null pointer representation into objects of type nullptr_t. That's a shame.

Sorry, that's my fault -- it's unintentional that we have different representations here. That said, is this optimization useful in C? (I'm struggling to understand why it's useful in C++ even). I imagine that in C++ this is useful for APIs that overload nullptr_t to provide a safer interface, but that's not really a common pattern in C.

[zygoloid]

In C++, exploiting this would allow us to remove a bunch of unnecessary stores of 0 that will never be read and unnecessary zeroing of registers in cases like passing nullptr to a nullptr_t constructor, forwarding function template, etc. It would make nullptr_t closer to the zero-overhead abstraction it ought to be.

In C, I find it a little hard to imagine uses of objects of type nullptr_t -- I'd expect nullptr is almost always immediately converted to a pointer type, since there's no possibility of forwarding or overload resolution or constructors getting involved. So maybe it doesn't really matter either way there.

The incompatibility is concerning though: C programmers might think they can create an object of type nullptr_t, cast its address to void**, and dereference it to get a null pointer -- which might work in C implementations (I can't tell what C intends to allow in the space of type punning here) but is definitely not guaranteed to work across the C/C++ boundary or in C++.

[AaronBallman]

In C++, exploiting this would allow us to remove a bunch of unnecessary stores of 0 that will never be read and unnecessary zeroing of registers in cases like passing nullptr to a nullptr_t constructor, forwarding function template, etc. It would make nullptr_t closer to the zero-overhead abstraction it ought to be.

I agree in theory, but in practice I'm less certain. I thought most of the overloads with nullptr_t are because the user wants to = delete; or have a different access level for the function to help catch silly mistakes, not because null is algorithmically important, right? Just trying to understand whether an ABI break would gain us enough to make the pain worth it. (We could make the changes and guard them with -fabi-version though.)

In C, I find it a little hard to imagine uses of objects of type nullptr_t -- I'd expect nullptr is almost always immediately converted to a pointer type, since there's no possibility of forwarding or overload resolution or constructors getting involved. So maybe it doesn't really matter either way there.

That's kind of my thinking.

The incompatibility is concerning though: C programmers might think they can create an object of type nullptr_t, cast its address to void**, and dereference it to get a null pointer -- which might work in C implementations (I can't tell what C intends to allow in the space of type punning here) but is definitely not guaranteed to work across the C/C++ boundary or in C++.

Oof, I don't think that kind of type punning is expected. I wonder if we should file an issue against C23 for this?