Does const allow for (theoretical) optimization here?

Question

Consider this snippet:

void foo(const int&);

int bar();

int test1()
{
    int x = bar();
    int y = x;
    foo(x);
    return x - y;
}

int test2()
{
             


        

Answer 1

The const helps very little to basically nothing for optimization. The compiler basically needs a global view on the code to decide if variables are truly constant or not, and the compiler will determine this regardless of the const modifiers. Consider this code (e.g. in godbolt.org)

void foo(const int& v) { const_cast<int&>(v) = 6; }
const int bar() { return 9; }
int main() {
     const int a = bar();
     const int b = a;
     foo(a);
     return a-b;
}

which will result for -O3 in gcc8.3 and clang7 to the very correct and optimal (even with the additional not-essential const_cast that causes undefined behavior):

foo(int const&):                              # @foo(int const&)
        mov     dword ptr [rdi], 6
        ret
bar():                                # @bar()
        mov     eax, 9
        ret
main:                                   # @main
        mov     eax, -3
        ret

and what is important: this is identical if you replace all const int by just int. Thus, it is not the const that helps the compiler, it is global code view and analysis.

In the end let me quote this very interesting GotW page from Herb Sutter http://www.gotw.ca/gotw/081.htm which as I see also started the whole issue.

Thus, const remains a feature predominately for programmers. Compilers are smarter than us and don't trust us anyway ;-)

And a final remark: optimization is in almost all cases a feature of the compiler and not of the language. There are some exceptions from that, e.g. copy elision, but the question of this issue is not one of them.

Answer 2

The standard says in [dcl.type.cv]:

Except that any class member declared mutable […] can be modified, any attempt to modify […] a const object […] during its lifetime […] results in undefined behavior.

It is also not possible to make this defined by ending the lifetime of the object prematurely, according to [basic.life]:

Creating a new object within the storage that a const complete object with […] automatic storage duration occupies, or within the storage that such a const object used to occupy before its lifetime ended, results in undefined behavior.

This means that the optimization of x - y to zero is valid because any attempt to modify x in foo would result in undefined behavior.

The interesting question is if there is a reason for not performing this optimization in existing compilers. Considering that the const object definition is local to test2 and the fact is used within the same function, usual exceptions such as support for symbol interposition do not apply here.