C++ Clang++ – Why operator() Copies Movable Temporaries in Clang and Understanding Copy Elision

c++c++23clangcopy-elisionexplicit-object-parameter

In the following C++23 program

struct A {
    A() {}
    A(A&&) = default;
    void f(this A) {}
    void operator() (this A) {}
};

int main() {
    A{}.f(); // ok
    A{}();   // Clang error
}

struct A is movable, and its member functions f() and operator() have explicit object parameter (this A).

In Clang compiler surprisingly A{}.f() works fine, but A{}() fails with the error:

<source>:10:5: error: call to implicitly-deleted copy constructor of 'A'
<source>:3:5: note: copy constructor is implicitly deleted because 'A' has a user-declared move constructor

Online demo: https://gcc.godbolt.org/z/hbfzMvE9f

Is there some difference between functions f() and operator() from the language standpoint that explains their observable treatment by the compiler?

Best Answer

This is a confirmed clang bug. The program is well-formed. The expression A{}() is equivalent to(interpreted as) A{}.operator()() which clang accepts. Since A{} is a prvalue(and hence an rvalue), the overloaded call operator A::operator()(this A) is a viable option here for the call A{}.operator()().

From over.call:

A function call operator function is a function named operator() that is a member function with an arbitrary number of parameters. It may have default arguments. For an expression of the form
postfix-expression ( expression-listopt )
where the postfix-expression is of class type, the operator function is selected by overload resolution ([over.call.object]). If a surrogate call function is selected, let e be the result of invoking the corresponding conversion operator function on the postfix-expression; the expression is interpreted as
e ( expression-listopt )
Otherwise, the expression is interpreted as
postfix-expression . operator () ( expression-listopt ) 

Related Solutions

C++ Performance – Why Changing 0.1f to 0 Slows Down Performance by 10x

Welcome to the world of denormalized floating-point! They can wreak havoc on performance!!!

Denormal (or subnormal) numbers are kind of a hack to get some extra values very close to zero out of the floating point representation. Operations on denormalized floating-point can be tens to hundreds of times slower than on normalized floating-point. This is because many processors can't handle them directly and must trap and resolve them using microcode.

If you print out the numbers after 10,000 iterations, you will see that they have converged to different values depending on whether 0 or 0.1 is used.

Here's the test code compiled on x64:

int main() {

    double start = omp_get_wtime();

    const float x[16]={1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8,1.9,2.0,2.1,2.2,2.3,2.4,2.5,2.6};
    const float z[16]={1.123,1.234,1.345,156.467,1.578,1.689,1.790,1.812,1.923,2.034,2.145,2.256,2.367,2.478,2.589,2.690};
    float y[16];
    for(int i=0;i<16;i++)
    {
        y[i]=x[i];
    }
    for(int j=0;j<9000000;j++)
    {
        for(int i=0;i<16;i++)
        {
            y[i]*=x[i];
            y[i]/=z[i];
#ifdef FLOATING
            y[i]=y[i]+0.1f;
            y[i]=y[i]-0.1f;
#else
            y[i]=y[i]+0;
            y[i]=y[i]-0;
#endif

            if (j > 10000)
                cout << y[i] << "  ";
        }
        if (j > 10000)
            cout << endl;
    }

    double end = omp_get_wtime();
    cout << end - start << endl;

    system("pause");
    return 0;
}

Output:

#define FLOATING
1.78814e-007  1.3411e-007  1.04308e-007  0  7.45058e-008  6.70552e-008  6.70552e-008  5.58794e-007  3.05474e-007  2.16067e-007  1.71363e-007  1.49012e-007  1.2666e-007  1.11759e-007  1.04308e-007  1.04308e-007
1.78814e-007  1.3411e-007  1.04308e-007  0  7.45058e-008  6.70552e-008  6.70552e-008  5.58794e-007  3.05474e-007  2.16067e-007  1.71363e-007  1.49012e-007  1.2666e-007  1.11759e-007  1.04308e-007  1.04308e-007

//#define FLOATING
6.30584e-044  3.92364e-044  3.08286e-044  0  1.82169e-044  1.54143e-044  2.10195e-044  2.46842e-029  7.56701e-044  4.06377e-044  3.92364e-044  3.22299e-044  3.08286e-044  2.66247e-044  2.66247e-044  2.24208e-044
6.30584e-044  3.92364e-044  3.08286e-044  0  1.82169e-044  1.54143e-044  2.10195e-044  2.45208e-029  7.56701e-044  4.06377e-044  3.92364e-044  3.22299e-044  3.08286e-044  2.66247e-044  2.66247e-044  2.24208e-044

Note how in the second run the numbers are very close to zero.

Denormalized numbers are generally rare and thus most processors don't try to handle them efficiently.

To demonstrate that this has everything to do with denormalized numbers, if we flush denormals to zero by adding this to the start of the code:

_MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);

Then the version with 0 is no longer 10x slower and actually becomes faster. (This requires that the code be compiled with SSE enabled.)

This means that rather than using these weird lower precision almost-zero values, we just round to zero instead.

Timings: Core i7 920 @ 3.5 GHz:

//  Don't flush denormals to zero.
0.1f: 0.564067
0   : 26.7669

//  Flush denormals to zero.
0.1f: 0.587117
0   : 0.341406

In the end, this really has nothing to do with whether it's an integer or floating-point. The 0 or 0.1f is converted/stored into a register outside of both loops. So that has no effect on performance.

C++ – How to Perform Move Elision in Explicit Object Member Functions for C++23

This is CWG2813. As the issue description notes, the wording in C++23 requires a glvalue for the left operand of the dot operator, which implies that if the left operand is a prvalue, it must be converted to a glvalue first (materialized), which prevents copy/move elision. This outcome is undesirable; we would like to have the prvalue initialize the explicit object parameter directly. So, a change was made to the wording and it was approved as a DR. It will take compilers a while to catch up, but the intent is that the example should be accepted.

Best Answer

Related Solutions

C++ Performance – Why Changing 0.1f to 0 Slows Down Performance by 10x

C++ – How to Perform Move Elision in Explicit Object Member Functions for C++23

Related Question