Does a boolean condition in a for loop that is always false get optimized away?

Question

I have the following situation

bool user_set_flag;

getFlagFromUser(&user_set_flag);

while(1){

    if(user_set_flag){
        //do some computation and output

    }


    //do other computation
}

The variable user_set_flag is only set once and only once in the code, at the very start, its essentially the user selecting what he wants to do with the program. Say that the user selects user_set_flag = false then will the compiler compile the code in such a way such that the if(user_set_flag) statement will only be checked once, or will it be always checked. Can I give the compiler hints like setting the bool to a const?

The reason I ask this is because my application is time-critical and it processes frames as fast as possible. A branch that is always false should be able to be determined at run-time somehow?

Answer 1

An alternative would be:

if(user_set_flag){
    while(1){
      ComputationAndOutput();
      OtherComputation();
    }
} else {
    while(1){
      OtherComputation();
    }
}

but as Smashery already said, this is micro-optimization and won't speed your program up as much as other optimizations you can surely do.

Answer 2

I don't think it's at all possible to optimize this any further. The compiler is smart enough to know that the value of user_set_flag is not going to change during the execution of the loop and will generate the most efficient machine code for that.

This is also somewhat in the realm of second-guessing the compiler. Unless you really really really know what you are doing its better to stick with the simplest solution.

As an exercise try to profile (time) the execution using both if (true) and if(user_set_flag). My guess would be that there is going to be zero difference in execution time.

Answer 3

You say that the user actually has a setting that can set this flag to true or false. That means that it's something that can change at runtime. Which means, it cannot be optimized away (usually).

In general, a compiler can only "optimize away" things it knows at compile time. Which means: at the moment you hit the "Build" item in your menu of your editor. If it can change, it - usually - cannot be optimized away.

However, it is rather easy (well, depending on the parts you didn't show) to optimize it away yourself. If you are bothered by the one assembly instruction this uses inside the loop, place the if-statement outside the loop. That way, it is only executed once for the call of the function.

Answer 4

Firstly, processors have a capability called branch prediction. After a few runs of the loop, the processor will be able to notice that your if statement always goes one way. (It can even notice regular patterns, like true false true false.) It will then speculatively execute that branch, and so long as it able to predict correctly, the extra cost of the if statement is pretty much eliminated. If you think that the user is more likely to choose true rather than false, you can even tell this to the gcc compiler (gcc-specific extension).

However, you did mention in one of your comments that you have a 'much more complicated sequence of bools'. I think it is possible that the processor doesn't have the memory to pattern-match all those jumps -- by the time it comes back to the first if statement, the knowledge of which way that jump went has been displaced from its memory. But we could help it here...

The compiler has the ability to transform loops and if-statements into what it thinks are more optimal forms. E.g. it could possibly transform your code into the form given by schnaader. This is known as loop unswitching. You can help it along by doing Profile-Guided Optimization (PGO), letting the compiler know where the hotspots are. (Note: In gcc, -funswitch-loops is only turned on at -O3.)

You should profile your code at the instruction level (VTune would be a good tool for this) to see if the if-statements are really the bottleneck. If they really are, and if by looking at the generated assembly you think the compiler has got it wrong despite PGO, you can try hoisting out the if-statement yourself. Perhaps templated code would make it more convenient:

template<bool B> void innerLoop() {
    for (int i=0; i<10000; i++) {
        if (B) {
            // some stuff..
        } else {
            // some other stuff..
        }
    }
}
if (user_set_flag) innerLoop<true>();
else innerLoop<false>();

Answer 5

If you know value of flag at compile time, you can add compilation flag for not including if statement as:

while(1){
   #ifdef user_set_flag
    {
        //do some computation and output

    }
   #endif


    //do other computation
}

Answer 6

Technically it is possible for the compiler to optimize situations like this.

For example:

#include <cstdio>

int main(int argc, char* [])
{
    while (true)
    {
        if (argc == 1) {
            puts("one");
        }
        puts("some more");
    }
}

main gets compiled to (G++ -O3):

    cmpl    $1, 8(%ebp)
    je  L9
    .p2align 4,,15
L2:
    movl    $LC1, (%esp)
    call    _puts
    jmp L2
L9:
    movl    $LC0, (%esp)
    call    _puts
    movl    $LC1, (%esp)
    call    _puts
    movl    $LC0, (%esp)
    call    _puts
    movl    $LC1, (%esp)
    call    _puts
    jmp L9

As you can see the condition is evaluated only once to determine which loop to run. And it has unrolled the true branch a bit :)

I would conclude that there is no reason to worry about these micro-optimizations, unless you determine that the compiler is not able to optimize away repeated evaluation of the unchanging boolean (e.g if it was global, how would the compiler know that it won't be modified by the function calls) and that it is indeed the bottleneck.

Answer 7

If you really want as-fast-as-possible, then you want to do aggressive performance tuning. So forget about trying to guess what the compiler might do to optimize your program.

That's being timid.

Instead, take charge. This shows you how.