Force compiler to not optimize side-effect-less statements

Question

I was reading some old game programming books and as some of you might know, back in that day it was usually faster to do bit hacks than do things the standard way. (Convert

Answer 1

a function call incurs quite a bit of overhead, so I would remove this anyway.

adding a dummy += i; is no problem, as long as you keep this same bit of code in the alternate profile too. (So the code you are comparing it against).

Last but not least: generate asm code. Even if you can not code in asm, the generated code is typically understandable since it will have labels and commented C code behind it. So you know (sortoff) what happens, and which bits are kept.

R

p.s. found this too:

 inline float pslNegFabs32f(float x){
       __asm{
         fld  x //Push 'x' into st(0) of FPU stack
         fabs
         fchs   //change sign
         fstp x //Pop from st(0) of FPU stack
        }
       return x;
 } 

supposedly also very fast. You might want to profile this too. (although it is hardly portable code)

Answer 2

Compilers are unfortunately allowed to optimise as much as they like, even without any explicit switches, if the code behaves as if no optimisation takes place. However, you can often trick them into not doing so if you indicate that value might be used later, so I would change your code to:

int float_to_int(float f)
{
    return static_cast<int>(f); // has no side-effects
}

As others have suggested, you will need to examine the assemnler output to check that this approach actually works.

Answer 3

If you are using Microsoft's compiler - cl.exe, you can use the following statement to turn optimization on/off on a per-function level [link to doc].

#pragma optimize("" ,{ on |off })

Turn optimizations off for functions defined after the current line:

#pragma optimize("" ,off)

Turn optimizations back on:

#pragma optimize("" ,on)

For example, in the following image, you can notice 3 things.

1. Compiler optimizations flag is set - /O2, so code will get optimized.
2. Optimizations are turned off for first function - square(), and turned back on before square2() is defined.
3. Amount of assembly code generated for 1st function is higher. In second function there is no assembly code generated for int i = num; statement in code.

Thus while 1st function is not optimized, the second function is.

See https://godbolt.org/z/qJTBHg for link to this code on compiler explorer.

A similar directive exists for gcc too - https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html

Answer 4

So I want to make sure when I profile, I'm not getting skewed results. As such, I'd like to make sure the compiler does not optimize out statements

You are by definition skewing the results.

Here's how to fix the problem of trying to profile "dummy" code that you wrote just to test: For profiling, save your results to a global/static array and print one member of the array to the output at the end of the program. The compiler will not be able to optimize out any of the computations that placed values in the array, but you'll still get any other optimizations it can put in to make the code fast.

Answer 5

A micro-benchmark around this statement will not be representative of using this approach in a genuine scenerio; the surrounding instructions and their affect on the pipeline and cache are generally as important as any given statement in itself.