What are the advantages if caller is responsible for argument destruction vs callee is responsible?

Question

In languages with well defined object lifetimes the destructors of by-value parameters have to be called at some point. This can be the responsibility of the caller or of the callee.

GCC and Clang compiling C++ for example decide to have the caller destroy the arguments. This can can lead to slightly inefficient code if the callee will always move the value out of the argument. For example after passing a std::unique_ptr by value, the caller must always check if the value was moved out of the argument and if not call operator delete on the pointer. Taking unique_ptr by value and moving out unconditionally is a common idiom and the check in the caller is always unnecessary in this case.

Here

#include <memory>

// Will always move out of p
void foo(std::unique_ptr<int> p);

void bar() {
    foo(std::make_unique<int>());
}

is lowered to

bar():
        push    rbx
        mov     edi, 4
        sub     rsp, 16
        call    operator new(unsigned long)
        lea     rdi, [rsp+8]
        mov     DWORD PTR [rax], 0
        mov     QWORD PTR [rsp+8], rax
        call    foo(std::unique_ptr<int, std::default_delete<int> >)
        mov     rdi, QWORD PTR [rsp+8]
        test    rdi, rdi                  ; Null pointer check here!
        je      .L1
        mov     esi, 4
        call    operator delete(void*, unsigned long)
.L1:
        add     rsp, 16
        pop     rbx
        ret
        mov     rbx, rax
        jmp     .L3
bar() [clone .cold]:

Rustc on the other hand generates code where the callee destroys the arguments. So the unique_ptr (or rather Box) example does not require an extra null pointer check.

Here

#[inline(never)]
pub fn foo(p: Box<i32>) {/*...*/}

pub fn bar() {
    foo(Box::new(0));
}

is lowered to

example::bar:
        push    rax
        mov     rax, qword ptr [rip + __rust_no_alloc_shim_is_unstable@GOTPCREL]
        movzx   eax, byte ptr [rax]
        mov     edi, 4
        mov     esi, 4
        call    qword ptr [rip + __rust_alloc@GOTPCREL]
        test    rax, rax
        je      .LBB1_1
        mov     dword ptr [rax], 0
        mov     rdi, rax
        pop     rax
        jmp     qword ptr [rip + example::foo@GOTPCREL] ; Tail call to foo, no cleanup afterwards
.LBB1_1:
        mov     edi, 4
        mov     esi, 4
        call    qword ptr [rip + alloc::alloc::handle_alloc_error@GOTPCREL]
        ud2

So what are the advantages of the "caller destroys arguments" approach?

And, if there are others beside the one mentioned above, what are the advantages of Rustc's "callee destroys arguments" approach?

Answer 1

TL;DR: It may well be historical.

Trip down memory lane

C++ was first standardized in 1998, though it had started its existed 15 years prior already. And only in C++11 were move semantics introduced.

This means that from 13 years (to 28 years) of its existence, moves were not. Instead, passing by value entailed copying the value -- possibly invoking a copy constructor.

In such a scheme, the caller is naturally responsible for cleaning up the value being copied -- if necessary -- and therefore well-suited to cleaning up the argument.

References & Pointers

Another possible justification for having the caller clean-up, is that whenever an argument is passed by reference or pointer, the caller will perform the clean-up already.

Thus, it seems in keeping to also have the caller be responsible for the one case where arguments are passed by value.

ABI Consideration

At the assembly level, arguments are passed either by register, or via the stack.

An arbitrarily large value cannot be passed by register -- today, I believe at most 2 registers are used to pass by value on x64 for example -- and therefore at the assembly level the caller reserves some stack space, initialize it, then passes a pointer to it.

This is symmetrical with the caller reserving some stack space and passing a pointer to it when returning large values, by the way.

It seems consistent to have the caller handle destruction, when it is already handling memory allocation.

ABI Optimization

One clever little trick used by many implementations is the so-called Red Zone.

Whenever a function is invoked which is:

1. A leaf function: a function invoking no other function.
2. A frugal function: a function using no more than 128 bytes on the stack.

Then this function skips setting up (and tearing down) a stack frame of its own.

This is a clever trick, as it both minimizes the size of those functions, and minimizes their execution time, even if they are not inlined.

Having the caller take care of the clean-up, rather than the callee, has the advantage of making more callees frugal, and thus eligible for Red Zone optimization. Whether this was foreseen or not, I know not.

Summary so far

Up until C++11, it is therefore "logical" for the caller to be the one cleaning up arguments passed by value.

There's a slight advantage (Red Zone) and it's otherwise in line with cleaning up all other arguments.

Moves enter the scene

When C++11 introduced moves, how to design moves was up in the air.

In the end, the design selected was user-provided move operators -- which automatically gated their introduction on existing types, to avoid introducing bugs -- and for the moved-out object to be left in an unspecified but valid state. In particular, the moved-out object has its destructor invoked.

This all very conservative, essentially mimicking the design of existing copy constructors -- including the "fake" copy-constructor that auto_ptr had at the time which transferred its pointee.

It also has the distinct advantage of being compatible with the existing ABI so far!

I know not whether anyone realized, then, that it was sub-optimal in a number of cases. Even if they did, compatibility may have trumped any such concern.

Conclusion

In the end, I am afraid that the not so satisfying answer is just "it is what it is", and that C++11 simply inherited the mechanics from C++98 (and prior). The migration to C++11 (libstdc++ std::string fiasco) was complicated enough as it is.

The Red Zone argument may still hold, and make the choice a trade-off, but with compilers nowadays inlining more, I'm not too convinced it's worth it.

Answer 2

I think the main reason is for backwards compatibility with C varargs (<cstdarg> header).

When C stadrgs are used, the callee does not necessarily know the types of the arguments -- it is legal to pass extra arguments that the callee does not use, and they still need to be cleaned up properly. By having the caller always clean up all arguments, this becomes much less of an issue.