Question

I know that using the const keyword on function arguments provides better performance, but I always forget to add it. Is the compiler (GCC in this case) smart enough to notice that the variabele never changes during the function, and compile it as if I would have added const explicitly?

Answer 1

Is the compiler (GCC in this case) smart enough to notice that the
variabele never changes during the function, and compile it as if I
would have added const explicitly?

Not necessarily. For example:

void some_function(int *ptr); // defined in another translation unit

int foo(int a) {
    some_function(&a);
    return a + 1;
}

The compiler can’t see what some_function does, so it can’t assume that it won’t modify a.

Link-time optimization could perhaps see what some_function really does and act accordingly, but as far as this answer is concerned I’ll consider only optimization for which the definition of some_function is unavailable.

int bar(const int a) {
    some_function((int*)&a);
    return a + 1;
}

The compiler can’t see what some_function does, but it can assume that the value of a does not change anyway. Therefore it can make any optimizations that apply: maybe it can keep a in a callee-saves register across the call to some_function; maybe it computes the return value before making the call instead of after, and zaps a. The program has undefined behavior if some_function modifies a, and so from the compiler’s POV once that happens it doesn’t matter whether it uses the “right” or “wrong” value for a.

So, by in this example by marking a const you have told the compiler something that it cannot otherwise know — that some_function will not modify *ptr. Or anyway that if it does modify it, then you don’t care what your program’s behavior is.

int baz(int a) {
    some_function(NULL);
    return a + 1;
}

Here the compiler can see all relevant code as far as the standard is concerned. It doesn’t know what some_function does, but it does know that it doesn’t have any standard means to access a. So it should make no difference whether a is marked const or not because the compiler knows it doesn’t change anyway.

Debugger support can complicate this situation, of course — I don’t know how things stand with gcc and gdb, but in theory at least if the compiler wants to support you breaking in with the debugger and modifying a manually then it might not treat it as unmodifiable. The same applies to the possibility that some_function uses platform-specific functionality to walk up the stack and mess with a. Platforms don’t have to provide such functionality, but if they do then it conflicts with optimization.

I’ve seen an old version of gcc (3.x, can’t remember x) that failed to make certain optimizations where I failed to make a local int variable const, but in my case gcc 4 did make the optimization. Anyway, the case I’m thinking of wasn’t a parameter, it was an automatic variable initialized with a constant value.

There’s nothing special about a being a parameter in any of what I’ve said — it could just as well be any automatic variable defined in the function. Mind you, the only way to for a parameter to get the effect of initialization with a constant value is to call the function with a constant value, and for the compiler to observe the value for that call. This tends to happen only when the function is inlined. So inlined calls to functions can have additional optimizations applied to them that the “out-of-line” function body isn’t eligible for.