I do not observe a meaningful optimization advantage of constexpr

Question

Thanks, I do not need any book to teach me what constexpr means. I am teaching constexpr and my simple example fails convincing students why they should use the advantage of compile time computation via constexpr.

Also please strictly avoid linking to questions such as this which has no assembly code or profiling and they are meaningless for my question.

---

I am looking for an example to show why constexpr is useful at all and it cannot be dismissed.

Well, in many cases if constexpr is replaced by const nothing wrong really happens. So, I designed the following examples:

main_const.cpp

#include <iostream>
using namespace std;

const int factorial(int N)
{
    if(N<=1)
        return 1;
    else 
        return N*factorial(N-1);
}

int main()
{
    cout<<factorial(10)<<endl;
    return 0;
}

and

main_constexpr.cpp

#include <iostream>
using namespace std;

constexpr int factorial(int N)
{
    if(N<=1)
        return 1;
    else 
        return N*factorial(N-1);
}

int main()
{
    cout<<factorial(10)<<endl;
    return 0;
}

But the problem is that for them former one, the assembly code is

main_const.asm

12:main_last.cpp **** int main()
13:main_last.cpp **** {
132                     .loc 1 13 0
133                     .cfi_startproc
134 0000 4883EC08       subq    $8, %rsp
135                     .cfi_def_cfa_offset 16
14:main_last.cpp ****   cout<<factorial(10)<<endl;
136                     .loc 1 14 0
137 0004 BE005F37       movl    $3628800, %esi
137      00
138 0009 BF000000       movl    $_ZSt4cout, %edi
138      00
139 000e E8000000       call    _ZNSolsEi

And for the latter one it is

main_constexpr.asm

12:main_now.cpp  **** int main()
13:main_now.cpp  **** {
11                      .loc 1 13 0
12                      .cfi_startproc
13 0000 4883EC08        subq    $8, %rsp
14                      .cfi_def_cfa_offset 16
14:main_now.cpp  ****   cout<<factorial(10)<<endl;
15                      .loc 1 14 0
16 0004 BE005F37        movl    $3628800, %esi
16      00
17 0009 BF000000        movl    $_ZSt4cout, %edi
17      00
18 000e E8000000        call    _ZNSolsEi
18      00

which means that the compiler has obviously performed a constant folding of (10!) = 3628800 for both cases either using cosnt or constexpr.

The compilation is performed via

g++ -O3 -std=c++17 -Wa,-adhln -g main.cpp>main.asm

Despite in most of the cases, many people assume the code now runs faster without any investigation, considering the fact that compilers are clever, I am wondering if there is any real, honest and meaningful optimization benefit behind constexpr?

Answer 1

For the sole purpose of optimization, it is impossible to construct a constexpr expression/function call sequence for which it is impossible for a compiler to optimize a non-constexpr equivalent. This is of course because constexpr has a number of requirements for its use. Any constexpr code must be inlined and visible to the compiler of that translation unit. Recursively, through all expressions that lead to the generation of a constexpr value.

Similarly, constexpr functions aren't allowed to do things like allocate memory (yet), do low-level function pointer manipulation (yet), call non-constexpr functions, and other such things that would prevent the compiler from being able to execute them at compile time.

As such, if you have a constexpr construct, an equivalent non-constexpr version would have all of these same properties of its implementation. And since the compiler must be able to execute constexpr code at compile-time, it would have to be at least theoretically able to do the same for the non-constexpr equivalent.

Whether it does optimize it or not in any particular case is irrelevant; such things change with every compiler version. The fact that it could is enough.

Your problem is that you believe that the primary purpose of constexpr is performance. That it's an optimization done to allow things you couldn't do otherwise.

The role of constexpr in performance is primarily that, by tagging a function or variable as constexpr, the compiler prevents you from doing things that implementations might not be able to execute at compile time. If you want compile-time execution across platforms, you have to stay within the standard-defined boundaries of compile-time execution.

The syntax means that the compiler actively prevents you from doing non-constexpr things. You cannot accidentally write code that can't be run at compile-time.

That is, the question you should be looking at is not whether constexpr code could be written the same way without it. It's whether you would have written the code in a constexpr way without the keyword. And for any system of complexity, the answer increasingly approaches "no", if for no other reason than that it is easy to accidentally do something that the compiler can't run at compile-time.

Answer 2

You have to use it in a constexpr expression to force compile time evaluation:

int main()
{
    constexpr int fact_10 = factorial(10); // 3628800
    std::cout << fact_10 << std::endl;
    return 0;
}

Else you rely of compiler optimization.

In addition, constexpr allows its usage whereas simple const won't be allowed:

So assuming:

constexpr int const_expr_factorial(int) {/*..*/}
int factorial(int) {/*..*/}

You have:

char buffer[const_expr_factorial(5)]; // OK
char buffer[factorial(5)]; // KO, might compile due to VLA extension

std::integral_constant<int, const_expr_factorial(10)> fact_10; // OK
std::integral_constant<int, factorial(10)> fact_10; // KO