Can a C++ compiler optimize away code when dealing with pointers?

Question

Hello,

With these two questions as background (first and second), I got curious about how much optimization a C++ compiler can perform when dealing with pointers? More specifically, I'm interested in how smart a compiler is when it optimizes away code which it may detect will never be run.

(Some may point out that this is a dupe of this question, which it may be, but this particular part of it was not entirely answered. So therefore I decided to start a new question which deals only with this concern.)

(I'm not a C++ expert, so I may be wrong in the following statements, but I'll give it a shot anyway). A C++ compiler may optimize away portions of code which it will recognize never to be executed or never exited (such as loops). Here is an example:

void test() {
    bool escape = false;

    while ( !escape ); // Will never be exited

    // Do something useful after having escaped
}

The compiler would most likely recognize that the loop will never be exited as the code never changes the value of escape so that the loop is exited. This makes the loop useless.

Now, if we were to change the variable to a pointer, would the compiler still optimize away the loop? Say the code looks like so:

void test( bool* escape ) {
    while ( *escape ); // Will this be executed?

    // Do something useful after having escaped
}

My suspicion is that the compiler will do away with the loop, or else the keyword volatile would be redundant, yes?. But what about when working with threads -- where it is in fact modified but outside the function, and maybe even outside that C++ file entirely -- would the compiler still remove the loop? Does it make a difference if the variable pointed to by escape is a global variable, or a local variable inside another function? Can the compiler make this detection? In this question, some say that the compiler will not optimize the loop if library functions are invoked inside the loop. What mechanisms are then in place when using library functions which prevent this optimization?

Answer 1

In the first case (while ( !escape );) the compiler will treat that as label: goto label; and omit everything after it (and probably give you a warning).

In the second case (while ( *escape );), the compiler has no way of knowing if *escape will be true or false when run, so it has to do the comaprision and loop or not. Note however, it only has to read the value from *escape once, i.e., it could treat that as:

 bool b = *escape;
 label:   if (b) goto label;

volatile will force it to read the value from '*escape' each time through the loop.

Answer 2

Remember that the C++ compiler doesn't know, or give two shits, about your threads. Volatile is all you've got. It's perfectly legal for any compiler to make optimizations that destroy multi-threaded code but run fine on single-threaded. When discussing compiler optimizations, ditch threading, it's just not in the picture.

Now, library functions. Of course, your function could have *escape changed at any time by any of those functions, as the compiler has no way to know how they work. This is especially true if you pass the function as a callback. If, however, you have a library where you have the source code, the compiler may dig in and discover that *escape is never changed within.

Of course, if the loop is empty, it will almost certainly just let your program hang, unless it can determine that the condition isn't true when it starts. Removing an empty infinite loop is not the job of the compiler, it's the job of the programmer's brain cells.

Answer 3

The generic problem with a question like this is that they often include a very unrealistic code snippet. A "what will the compiler do" question needs real code. Since compilers were designed and optimized to compile real code. Most compilers will completely eliminate the function, and the function call, since the code has no side-effects. Leaving us with a question that doesn't have a useful answer.

But, sure, you are leaning towards finding a use for the volatile keyword. You can find many threads on SO talking about why volatile isn't appropriate in a multi-threaded app.

Answer 4

There's a difference in what the compiler is allowed to do, and what real compilers do.

The Standard covers this in "1.9 Program execution". The standard describes a sort of abstract machine, and the implementation is required to come up with the same "observable behavior". (This is the "as-if" rule, as documented in a footnote.)

From 1.9(6): "The observable behavior of the abstract machine is its sequence of reads and writes to volatile data and calls to library I/O functions." This means that, if you can show that a modification to a function will cause changes to neither, either in that function or after it's called, the modification is legal.

Technically, this means that if you write a function that will run forever testing (say) Goldbach's Conjecture that all even numbers greater than 2 are the sum of two primes, and only stopping if it finds one that isn't, a sufficiently ingenious compiler could substitute either an output statement or an infinite loop, depending on whether the Conjecture is false or true (or unprovable in the Goedel sense). In practice, it will be a while, if ever, before compilers have theorem provers better than the best mathematicians.