Document number: P0889R1
Project: Programming Language C++
Audience: Evolution Working group, Core Working group
 
Antony Polukhin, Yandex.Taxi Ltd, <antoshkka@gmail.com>, <antoshkka@yandex-team.ru>
 
Date: 2019-01-09

Ultimate copy elision

“...take no action on CWG #6 issue until an interested party
produces a paper with analysis and a proposal.”

― CWG #6

Significant changes since P0889R0 are marked with blue.

Show deleted lines from P0889R0.

I. Quick Introduction

[class.copy.elision] in the current working draft [N4713] provides a whitelist of cases when copy elision is permitted. Those rules are good! However they do not take into account that modern compilers could inline functions and do other optimizations.

This paper motivates and proposes to relax the [class.copy.elision] rules in order to allow compilers to produce much better code by mixing copy elision, inlining and other optimizations. It also addresses CWG #6, CWG #1049, and CWG #1579. It also gives a non-guaranteed solutions for CWG #2327.

II. The pitfall

A. Teaching practice

For decades, almost all teaching materials were telling people to decompose their programs into functions for maintainability and code re-usability. That good advice leads to code with numerous functions. Compiler developers noted that and started inlining functions more aggressively.

Currently inlining is one of the major optimizations [Understanding Compiler Optimization, 26m20s by Chandler Carruth] and compilers inline a lot.

B. Copy elision rules

Current rules for copy elision mostly assume that a function from source code remains a function in a binary. This works perfectly fine in a world without inlining, aliasing reasoning, and link time optimization. But if the function is inlined, then the compiler "sees" the whole function body along with function parameters. This unleashes a whole new world of possible optimizations (See section III for examples), but existing copy elision rules prevent those optimizations.

Our current rules are suboptimal for modern compilers: they prevent optimizations.

C. std::move/rvalues is not a panacea

We have std::array, std::basic_string, std::function, std::variant, std::optional and other classes that may store a lot of data on the stack. "Moving" instances of those classes may result in copying a lot of bytes.

Copy elision could be more profitable.

D. std::move/rvalues rules may be obscure

What is the optimal way to return something from a function? For named object we must just return. For a subobject we must return it with std::move. For a function parameter we must return it by std::move. If we return a reference to a local object, we have to std::move it. We must also return elements from structured binding via std::move, but only if the element is not a reference to an value returned by reference before decomposition... Do we have to apply std::move for a member function call on a local variable when the function call returns reference?..

Beginners and even some advanced programmers do not always know about those obscure rules and already assume that the compiler will do the job for them.

E. In sum

We have for decades been teaching people to write functions. WG21 was improving the C++ language by providing features for advanced programmers to optimize the functions, leaving behind the abilities of modern compilers to do that job sometimes better and sometimes out-of-the-box.

III. History of the problem

First copy elision rules were proposed in 1995 in N0641 "Copy optimization". Those rules were quite close to what was proposed in the early versions of this paper. Here they are:

Whenever a class object is copied and the implementation can prove that either the original or the copy will never again be used, an implementation is permitted to treat the original and the copy as two different ways of referring to the same object and not generate a copy at all. In that case, the object is destroyed at the later of the times when the original and the copy would have been destroyed without the optimization.

N0641 "Copy optimization" was adopted into the C++ WD in N0661 "WG21 Meeting No. 12". Two years later issues were found and described in N1079 "Core WG List of new issues":

I think the problem can be summarized by saying that objects can bind resources, and even if an object is not used, the resource it binds might be. The kind of thing that might happen is:

  Thing x = /* some value */;
  SubThing y = x.extract_portion();
  Thing z = x;
  z.clobber_portion();
  // now try to fetch the value of y

If x is never used again, the compiler is entitled to alias z and x. However, if y actually refers to part of the storage that x used, clobbering z (which is an alias to x) might also clobber y.

That issue was discussed multiple times, including N1108 "WG21 Meeting No. 19". In that paper two cases where Core especially wanted to allow copy elisions were highlighted:

Core would conduct further work to look at other optimizations.

Finally, in N1182 "Proposed Resolutions for Core Language Issues 6, 14, 20, 40, and 89" appeared the copy elision rules close to the ones we have now. Since then we have an open issue CWG #6 as a reminder that C++ could do better than now.

IV. Analysis

Part I

As was noted in N1079 object could "bind" its resources to other objects:

char* some;

struct binds_resource {
    binds_resource() = default;
    binds_resource(const binds_resource& other) = default;

    void bind() {
        some = data.data();
    }

    string data = "A";
};


void test() {
    binds_resource original{};
    original.bind();

    shared_state copy{original};
    copy.data = "B";
    assert(some != copy.data);
}

If in the above example we enable to elide copy and use original instead, then the assertion will fail.

Let's concentrate on a simpler case, when the original object is not accessed between construction and copying and when the original object is not accessed after copying and destruction. For such a simple case we still may get into trouble, if the original object "binds" its resources in constructor:

char* some;

struct binds_resource {
    binds_resource()
        : data{"A"}
    {
        bind();
    }

    binds_resource(const binds_resource& other) = default;

    void bind() {
        some = data.data();
    }

    string data = "A";
};


void test() {
    binds_resource original{};
    shared_state copy{original};
    copy.data = "B";
    assert(some != copy.data);
}

Such binding could also happen via constructor output parameters:

struct binds_resource {
    binds_resource(char** out)
        : data{"A"}
    {
        *out = data.data();
    }

    binds_resource(const binds_resource& other) = default;
    string data = "A";
};


void test() {
    char* some;
    binds_resource original{&some};

    shared_state copy{original};
    copy.data = "B";
    assert(some != copy.data);
}

More problems. We may get into troubles with eliding copies of resources that are used by different threads:

mutex m;

void takes_by_copy(std::string v) noexcept {
    m.unlock();
    v += "Oops."; // must work with copy!
}

void test() {
    m.lock();

    std::string original{"some string that is too big for SSO"};

    std::thread t{
        [&original]() {
            m.lock();
            // under the lock
            // ...
        }
    };

    takes_by_copy(original);

    t.join();
}

Note that the scope of the Source should remain the same or extend after the elision:

struct locked_mutex {
    mutex m{};
    lock_guard<mutex> lock{m};
};

void test() {
    shared_ptr<locked_mutex> original = std::make_shared<mutex>();

    // acessing resource that should be protected by lock

    shared_state copy{original};
}

Finally, we may get into troubles with eliding copies between different threads of execution:

void test() {
    some_shared_spin_guard original{spinlock};

    std::thread{
        [](const auto& lock) { /* under the lock */ },
        original
    }.detach();

    // original should be destroyed here and should release the lock here!
}

Conclusion: carefully investigating all the above cases we could enable the copy elisions for the case when:

Benefits: With above rules we get copy elisions in the following popular cases:

Case 1. CWG #6

void takes_by_copy(std::string v) noexcept { /* ... */ }

void example() {
    string v{"some string that is too big for SSO"};
    takes_by_copy(v);
}

Case 2. CWG #6

void takes_by_creference(const std::string& v) noexcept {
    std::string copy{v};
    /* ... */
}

void example() {
    return takes_by_creference("some string that is too big for SSO");
}

As Jens Maurer noted a sligtly modified example leads to UB: 'Given your copy elision rules, it seems "copy" could alias "s", introducing undefined behavior (see 9.1.7.1 [dcl.type.cv] p4).'

void takes_by_creference(const std::string& v) noexcept {
    std::string copy{v};
    copy += "blah";
}

void example() {
    const std::string s("some string);
    return takes_by_creference(s);
}

This paper proposes to adjust [dcl.type.cv] p4 making that behavior well defined.

Case 3. CWG #1049

struct B {
   string a;
   B(const string& a): a(a) { }
};

int main() {
   B("some string that is too big for SSO");
}

Part II: Source leaves scope

Now let's concentrate on another case: when the source object is destroyed right after the copy/move construction:

char* some;

struct binds_resource {
    binds_resource()
        : data{"A"}
    {
        bind();
    }

    binds_resource(const binds_resource& other) = default;

    void bind() {
        some = data.data();
    }

    string data = "A";
};

void test() {
    auto generate = []() {
        binds_resource source{};
        return source; // NRVO is possible
    };

    auto copy = generate();

    copy.data = "B";
    assert(some != copy.data); // UB
}

Existing rules already rely on the fact that the object that leaves scope should not be referenced outside the scope. Let's change example to have no UB:

shared_ptr<int> some;

struct shares_state {
    shares_state()
        : data{make_shared<int>(42)}
    {
        bind();
    }

    shares_state(const shares_state& other) {
        data = make_shared<int>(*other.data);
    }

    void bind() {
        some = data;
    }

    shared_ptr data;
};

void test() {
    auto generate = []() {
        shares_state source{};
        return source; // NRVO is possible
    };

    auto copy = generate();

    *copy.data = 0;
    assert(*some != *copy.data); // Implementation defined
}

In other words: we don't have to check for "binding" if the scope of Source ends right after the copy/move construction.

Conclusion: we can relax the rule in "Part I" for the cases when the scope of Source ends immediately after the copy/move construction:

Benefits: With above rules we get copy elisions in the following popular cases:

Case 1. Returning a function parameter

string callee(string v) {
    // any code
    return v;  // copy could be elided
}

auto example() {
    auto v = callee("some string that is too big for SSO");
    return v.size();
}

Case 2. Returning a reference to a local

string callee() {
    string v{"some string that is too big for SSO"};
    const auto& ref = v;
    return ref;  // copy could be elided
}

auto example() {
    auto v = callee();
    return v.size();
}

Case 3. Move by mistake

string callee() {
    string v{"some string that is too big for SSO"};
    return std::move(v);  // copy could be elided
}

auto example() {
    auto v = callee();
    return v.size();
}

Part III: Simple destructors and constructors

It may be hard to implement the above copy elision logic without taking additional care of compiler specifics. Some compilers at certain stages of optimization may inline constructors/destructors and just call the constructors/destructors of the members. So in the assembly (and probably in the IR) code like:

void test1() {
    std::pair<A, A> pair;
    (void)pair;
}
may look like:
test1():
  push rbp
  sub rsp, 16
  mov rdi, rsp
  call A::A()
  lea rdi, [rsp+8]
  call A::A()
  lea rdi, [rsp+8]
  call A::~A()
  mov rdi, rsp
  call A::~A()
  add rsp, 16
  pop rbp
  ret

With such representations it could be hard to distinguish `pair` objects from `A` objects. To minimize the changes required to implement the elision rules this paper proposes to allow eliding subobjects, while the elision rules from "Part I" and "Part II" are not violated.

Note that the proposed changes may change the destruction order of nested objects:

string callee() {
    pair<string, string> v = foo();
    return v.second;
}

auto test() {
    auto v = callee();
    return v.size();
}


auto pseudocode_with_proposed_changes() {
    pair<string, string> v = foo();
    v.first.~string();
    return v.size();
    // do not call destructor of `v`, just destroy `v.second`
}

Let's invent an example where such optimization could break some code:

struct local_vector {
    pmr::monotonic_buffer_resource mr;
    pmr::vector<int> data{&mr};
};

auto callee() {
    local_vector lv;
    lv.data.resize(1000, 42);

    return lv.data; // copying
}

auto test() {
    auto v = callee(); // `mr` is destroyed, but during copying default memory resource is used
    /*...*/
}

With the proposed copy elision rules the above example becomes broken: there'll be no copying so the old memory resource will be used, that is destroyed.

Note that the example is already shaky. Minor changes result in broken code:

auto callee0() {
    monotonic_buffer_resource mr;
    pmr::vector<int> v(&mr);
    v.resize(1000, 42);
    return v;
}

auto test0() {
    auto v = callee(); // Already broken
}

In this paper we'd like to suggest enabling copy elision for the above rules and make an emergency hatch for disabling copy/move elisions for cases like above.

Conclusion: relax the rule in "Part II" by allowing copy elision for subobjects and make an "emergency hatch" for cases when copies are required. See "VII. Proposed wording" for the wording.

Benefits: With above rules we get copy elisions in the following popular cases:

Case 1. Returning a subobject

static string callee() {
    pair<string, string> v;
    return v.second;
}

Case 2. Returning an element from a structured binding

static string callee() {
    auto [f, s] = pair{};
    return s;
}

Case 3. CWG #1579

  optional<T> foo() {
    T t;
    ...
    // inlining the constructor of `optional` may result in internal storage of optional being
    // initialized by constructing T from `t`, which scope ends.
    return t; 
  }

III. Examples of possible optimizations

All the examples in this section use the following classes and assume that callee is inlined by the optimizer:

struct detect_copy {
    detect_copy() noexcept = default;
    detect_copy(const detect_copy&) noexcept;
    ~detect_copy();
    int modify() noexcept;
};

struct pair {
    detect_copy first, second;
};

A. Returning a function parameter

string callee(string v) {
    // any code
    return v;
}

auto example() {
    auto v = callee("some string that is too big for SSO");
    return v.size();
}

[class.copy.elision] forbids copy elision if a function parameter is returned. However, modern compilers do inline the callee. This results in a copy constructor call immediately followed by a call to the destructor: https://godbolt.org/g/nYovU3.

Code could be optimized by the compiler to the following, avoiding calls to the copy constructor and destructor:

int caller() {
    detect_copy v;
    return v.modify();
}

B. Returning a reference to a local

static detect_copy callee() {
    detect_copy v;
    auto& ref = v;
    return ref;
}

int caller() {
    return callee().modify();
}

[class.copy.elision] forbids copy elision if a reference is returned. However, modern compilers do understand that ref is just a reference to v. This can be seen from the assembly, where no separate variable/register is used for a ref: https://godbolt.org/g/YMAAN4. Note the call to the copy constructor immediately followed by a call to the destructor.

It means that the code could be optimized by the compiler to avoid calls to the copy constructor and destructor:

int caller() {
    detect_copy v;
    return v.modify();
}

C. Returning a subobject

static detect_copy callee() {
    pair v;
    return v.second;
}

int caller() {
    return callee().modify();
}

[class.copy.elision] forbids copy elision if a subobject is returned. However modern compilers do understand that pair could be treated as two detect_copy variables because pair has a default destructor. The copy constructor call is immediately followed by a call to the destructor for the same register: https://godbolt.org/g/kyPR7R.

Code could be optimized by the compiler to avoid calls to the copy constructor and destructor:

int caller() {
    detect_copy first;
    { detect_copy second; }
    return first.modify();
}

D. Returning a union element

union optional {
    bool fake;
    detect_copy data;

    optional()
        : data{}
    {}

    ~optional(){
        data.~detect_copy();
    }
};

static detect_copy callee() {
    optional v;
    return v.data;
}

int caller() {
    return callee().modify();
}

[class.copy.elision] forbids copy elision if a union element is returned. However modern compilers have knowledge of the active union member, because they do check that in constexpr calls. In the above example, the copy constructor call is immediately followed by a call to the destructor for the same memory: https://godbolt.org/g/Udb7vN.

Code could be optimized by the compiler to avoid calls to the copy constructor and destructor:

int caller() {
    detect_copy v;
    return v.modify();
}

E. Returning an element from a structured binding

static detect_copy callee() {
    auto [f, s] = pair{};
    return s;
}

int caller() {
    return callee().modify();
}

[class.copy.elision] forbids copy elision if a reference to the subobject is returned. However, modern compilers do understand that s is just a reference to pair{}.second. This can be seen from the assembly, where no separate variable/register is used for a s: https://godbolt.org/g/quV9Cp. Note the call to the copy constructor immediately followed by a call to the destructor for the same memory.

Code could be optimized by the compiler to avoid calls to the copy constructor and destructor:

int caller() {
    detect_copy first;
    { detect_copy second; }
    return first.modify();
}

F. Returning a local variable that is std::moved in return

static detect_copy callee() {
    detect_copy v;
    return static_cast<detect_copy&&>(v);
}

int caller() {
    auto v = callee();
    return v.modify();
}

[class.copy.elision] forbids copy elision if an rvalue reference is returned. However modern compilers do understand that actually v is returned. This can be seen from the assembly, where the compiler operates with just an address of v and does not use separate variables/registers for a reference: https://godbolt.org/g/bPQ8Ja. Note the call to the copy constructor immediately followed by a call to the destructor.

It means that the code could be optimized by the compiler to avoid calls to the copy constructor and destructor:

int caller() {
    detect_copy v;
    return v.modify();
}

H. Returning a reference to a subobject of a local object

class stringstream {
    detect_copy internal;

public:
    detect_copy& str() { return internal; }
};

static detect_copy callee() {
    stringstream ss;

    return ss.str();
}

int caller() {
    return callee().modify();
}

[class.copy.elision] forbids copy elision in that case. Thou the compilers succeeded in understanding and inlining the stringstream::str() function: https://godbolt.org/g/MjEocB. Note the call to the copy constructor immediately followed by a call to the destructor.

Code could be optimized by the compiler to avoid calls to the copy constructor and destructor:

int caller() {
    return detect_copy{}.modify();
}

I. Storing a parameter in a class

struct B {
   detect_copy a;
   B(const detect_copy& a): a(a) { }
};

int main() {
   (B(detect_copy()));
}

[class.copy.elision] forbids copy elision in that case. This issue was reported in CWG #1049.

In the disassembly, we see a call to the copy constructor is immediately followed by a call to the destructor: https://godbolt.org/g/zFWJNc.

IV. General idea

All the examples from above were producing code that after inlining (and some other optimizations) contains copy/move constructor call followed by a call to destructor. Something close to the following could be found in disassembly:

V. Implementability example.

Let's take a look at some pseodocode representing the C++ program after the inlining optimization:

struct A {
    A() __attribute__ ((pure)); // "pure" is detected by the compiler
    A(const A&);
    A(A&&) = default __attribute__ ((pure)); // "pure" is detected by the compiler
    ~A();

    int some_function();
private:
    // members
};

int caller() {
    A a;
    a.some_function();
    A b{a};             // scope of `a` ends immediately after the copy constructor call, eliding `b` and using `a` with extended scope
    [[end of scope `a`]]

    A c{b}; // `a` is accessed between this line, no copy elision allowed
    A d{c}; // `c` is not accessed after copy construction and its copy constructor is a "pure" function. OK to elide
    return d.some_function()
}
    
    

VI. Addressing common concerns


Concern 1: Eliding copy/move constructors could break user code

Response: For the rules from "Part I" nothing should get broken. For the remaining cases... Yes, but only if the following generally-accepted constraint for a copy constructor is not satisfied: "After the definition T u = v;, u is equal to v".

Although the constraint seems very restrictive at first, that constraint is satisfied by every sane copy constructor. Moreover the C++ Language and Standard Library heavily rely on it:

In other words, WG21 has been relying on that constraint for a long time and classes that violate that constraint are already unportable.


Concern 2: The examples do not look like a real world code. Nobody writes such bad code

Response: Examples are simplified just to show that the optimization is possible.

Real code would have functions located in different headers, more code will be in the function body. We searched the Yandex code base for return.*first; and return.*second; and found thousands of matches. Note that we searched only for a single optimization case for only a std::pair. Tuples, aggregates and more complex data types are also affected.


Concern 3: Advanced optimizations could affect compilation time

That depends. Making a high level optimization could be faster than doing a lot of low level optimizations. For example removing the copy constructor and destructor could be faster than inlining both and optimizing all the internals.

Anyway, to implement or not to implement a particular optimization is up to the compiler developers. This proposal just attempts to untie their hands and allow more optimizations.


Concern 4: It is impossible to implement some of the optimizations right now.

Response: This proposal does not require any of the optimizations from examples. The proposal simply attempts to relax copy elision rules to allow those optimizations someday.


Concern 5: We want an emergency hatch to disable copy elision for particular places.

Response: Our usual practice to disable optimizations for a variable is to make it volatile. This feature must be kept.


Concern 6: The optimizations are not guaranteed, so users still have to write std::move

Response: That's true. Proposals for automatically applying std::move may be a good idea. Such proposals would be more restrictive than the copy elision rules because we have no control over all the compiler inlining and reasoning logic. We can not guarantee that all the compilers would be able to inline some function or would be able to understand that the reference references a local object.

Moving in both directions would produce better results:


Concern 7: How this would change the guidelines? How shall users write their code to get the benefits of this optimization?

Response: This optimization won't change the guidelines in the nearest future. Treat this optimization as one of the compiler optimizations that you could not directly control, like inlining, jump threading, loop fusion, or common subexpression elimination.

Some guidelines may change after major compilers adopt the optimization. In that case, there could be found a common pattern that triggers it and that pattern could be taught. Probably the existing guidelines some day would evolve into "If you've got a function bigger than 15 lines of code, you may use std::move for returning objects that are not constructed at the beginning of the function. Otherwise just return the value."


Concern 8: Extracting a subobject from an object is scary. I can no longer assume that the object I construct as a subobject is in any way part of myself, nor can it assume that any sibling subobjects will always be around.

Response: The proposed wording makes sure that the subobject is not used between copy/move construction and destruction. An object that is constructed as a subobject is a part of the object as long as you use it as a subobject. As soon as you copy/move and destroy it, you can not use it any more by existing C++ rules. That's the place where the optimization steps in, removing the copy/move+destruction and reusing the subobject.


Concern 9: The problem is not that big because compilers could inline the constructors and destructors and then optimize the resulting code

Response: Yes, they do that. But the resulting code is still suboptimal, because even for std::string compilers could not optimize away all the dead stores. Consider the following example:

#include <utility>
#include <string>

std::pair<std::string, std::string> produce();

static std::string first_non_empty_move() {
    auto v = produce();
    if (!v.first.empty()) {
        return std::move(v.first);
    }
    return std::move(v.second);
}

int example_1_move() {
    return first_non_empty_move().size();
}

Note that std::move is used and everything must be optimal. But it's not, because with this paper's proposed copy elision rules, the resulting code could still be much shorter and with fewer conditional jumps:

Without copy elisionWith copy elision
https://godbolt.org/g/3xZvtwhttps://godbolt.org/g/RiTmPE
example_1_move():
    push    rbp
    push    rbx
    sub     rsp, 104
    lea     rdi, [rsp+32]
    mov     rbx, rsp
    call    produce[abi:cxx11]()
    mov     rax, QWORD PTR [rsp+40]
    test    rax, rax
    je      .L2
    lea     rdx, [rbx+16]
    lea     rcx, [rsp+48]
    mov     QWORD PTR [rsp], rdx
    mov     rdx, QWORD PTR [rsp+32]
    cmp     rdx, rcx
    je      .L13
    mov     QWORD PTR [rsp], rdx
    mov     rdx, QWORD PTR [rsp+48]
    mov     QWORD PTR [rsp+16], rdx
.L4:
    mov     QWORD PTR [rsp+8], rax
    lea     rax, [rsp+48]
    mov     rdi, QWORD PTR [rsp+64]
    mov     QWORD PTR [rsp+40], 0
    mov     BYTE PTR [rsp+48], 0
    mov     QWORD PTR [rsp+32], rax
    lea     rax, [rsp+80]
    cmp     rdi, rax
    je      .L6
    call    operator delete(void*)
    jmp     .L6
.L2:
    lea     rax, [rbx+16]
    lea     rdx, [rsp+80]
    mov     QWORD PTR [rsp], rax
    mov     rax, QWORD PTR [rsp+64]
    cmp     rax, rdx
    je      .L14
    mov     QWORD PTR [rsp], rax
    mov     rax, QWORD PTR [rsp+80]
    mov     QWORD PTR [rsp+16], rax
.L8:
    mov     rax, QWORD PTR [rsp+72]
    mov     QWORD PTR [rsp+8], rax
.L6:
    mov     rdi, QWORD PTR [rsp+32]
    lea     rax, [rsp+48]
    cmp     rdi, rax
    je      .L9
    call    operator delete(void*)
.L9:
    mov     rdi, QWORD PTR [rsp]
    add     rbx, 16
    mov     rbp, QWORD PTR [rsp+8]
    cmp     rdi, rbx
    je      .L1
    call    operator delete(void*)
.L1:
    add     rsp, 104
    mov     eax, ebp
    pop     rbx
    pop     rbp
    ret
.L14:
    movdqa  xmm0, XMMWORD PTR [rsp+80]
    movaps  XMMWORD PTR [rsp+16], xmm0
    jmp     .L8
.L13:
    movdqa  xmm0, XMMWORD PTR [rsp+48]
    movaps  XMMWORD PTR [rsp+16], xmm0
    jmp     .L4
    
    example_1_optimized():
    push    rbx
    sub     rsp, 64
    mov     rdi, rsp
    call    produce[abi:cxx11]()
    mov     rax, QWORD PTR [rsp+8]
    test    rax, rax
    mov     ebx, eax
    jne     .L3
    mov     ebx, DWORD PTR [rsp+40]
.L3:
    mov     rdi, QWORD PTR [rsp+32]
    lea     rax, [rsp+48]
    cmp     rdi, rax
    je      .L4
    call    operator delete(void*)
.L4:
    mov     rdi, QWORD PTR [rsp]
    lea     rdx, [rsp+16]
    cmp     rdi, rdx
    je      .L1
    call    operator delete(void*)
.L1:
    add     rsp, 64
    mov     eax, ebx
    pop     rbx
    ret
    

Inlining the constructors and destructors and optimization of the resulting code fails in many cases:

VII. Proposed wording: Ultimate solution for relaxing [class.copy.elision]

Adjust the [class.copy.elision] paragraph 1 to allow copy elision of all objects and subobjects:

This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):

– in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object (other than a function parameter or a variable introduced by the exception-declaration of a handler (18.3)) with the same type (ignoring cv-qualification) as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function call’s return object

– in a throw-expression (8.17), when the operand is the name of a non-volatile automatic object (other than a function or catch-clause parameter) whose scope does not extend beyond the end of the innermost enclosing try-block (if there is one), the copy/move operation from the operand to the exception object (18.1) can be omitted by constructing the automatic object directly into the exception object

– when the exception-declaration of an exception handler (Clause 18) declares an object of the same type (except for cv-qualification) as the exception object (18.1), the copy operation can be omitted by treating the exception-declaration as an alias for the exception object if the meaning of the program will be unchanged except for the execution of constructors and destructors for the object declared by the exception-declaration. [ Note: There cannot be a move from the exception object because it is always an lvalue. — end note ]

Copy elision isAbove copy elisions are required where an expression is evaluated in a context requiring a constant expression (8.6) and in constant initialization (6.8.3.2). [ Note: Copy elision might not be performed if the same expression is evaluated in another context. — end note ]

Additionally, copy elision is allowed for any non-volatile object with automatic storage duration and its non-volatile subobjects if source is not accessed between a copy/move construction of it and its destruction.:

For the above cases lifetime of the source after the elision extends to the lifetime of the target.

Adjust the [dcl.type.cv] paragraph 4 to avoid UB for elided copies:

Except that any class member declared mutable ([dcl.stc]) and any elided non-const target ([class.copy.elision]) can be modified, any attempt to modify ([expr.ass], [expr.post.incr], [expr.pre.incr]) a const object ([basic.type.qualifier]) during its lifetime ([basic.life]) results in undefined behavior.

VIII. Other ways of relaxing [class.copy.elision]

We could deal with each of the elision cases from the Section III of this paper separately. Such an approach is used in our companion P0878 paper. But note that such an approach is not generic, consumes considerable time, and scales badly because it attempts to allow a specific optimization without a way to inspect the abilities of all the compilers. This increases a risk of spending a lot of time on a case that would not be implementable in the nearest future or spending a lot of time on a case that is not profitable for that particular compiler.

It seems better to allow compiler developers to choose optimizations, as they are the ones who know the weak and strong parts of the underlying optimizer.

VIII. Acknowledgements

Many thanks to Walter E. Brown for fixing numerous issues in draft versions of this paper.

Many thanks to Jens Maurer for providing multiple comments and for pointing to the UB.

Many thanks to Marc Glisse for providing a reference to CWG #1049.

Many thanks to Nicol Bolas for raising many concerns.