What do I have to do to get a function called in compiler optimized code?

Question

I am working on and ios project compiling with Apple LLVM 4.0 with optimizations. I implemented two different versions of a function, one in C and one in NEON. I wanted to test their performance against one another. My idea was to call them both the same amount of times and then look them up in Time Profiler to see the relative time spent in each. Originally my code looked like

used_value = score_squareNEON(patch, image, current_pos);
used_value = score_squareC(patch, image, current_pos);

When I profiled the time the NEON code did not appear at all. Next I tried

for(int i = 0; i < successively_bigger_numbers; i++)
{
    used_value = score_squareNEON(patch, image, current_pos);
{
used_value = score_squareC(patch, image, current_pos);

Still no contribution from NEON code. Next was

used_value = score_squareNEON(patch, image, current_pos);
test = score_squareC(patch, image, current_pos);

where test never got read. Nothing. Then

test = score_squareNEON(patch, image, current_pos);
test = 0;
other_used_variable += test;
used_value = score_squareC(patch, image, current_pos);

Still nothing. What finally made it execute both functions was

value = score_squareNEON(patch, image, current_pos);
test = score_squareC(patch, image, current_pos);
...
min = (value+test)/2; //before it was min=value;

Also very important. The functions were both defined in the same file in which I was calling them. When I tried moving the function declarations to a different file both of them are called in every example.

First off, I have gained a lot of respect for compilers. Second, what exactly do I have to do to make sure a function is called? This has made me start to question all the things I have timed before. What if in the normal pattern of

timerStart();
functionCall();
timerEnd();

the function in the middle gets optimized out completely? Do I need to start checking for this somehow every time or is there a trick I can use? What are the rules governing when a compiler can optimize out an entire function call?

Answer 1

Also very important. The functions were both defined in the same file in which I was calling them. When I tried moving the function declarations to a different file both of them are called in every example.

When the compiler can prove that a function call has no side effect, and its result is not used, it can remove the call. If it can't prove that, the call cannot be removed because as far as the compiler can tell, the function may have side effects, and those mustn't be eliminated.

Declaring the variable the result of the function call is assigned to¹ should be enough to force the compiler to leave the function call in the program (6.7.3, paragraph 7 in N1570):

An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. What constitutes an access to an object that has volatile-qualified type is implementation-defined.

For C++ the guarantees are a little less unambiguous, as far as I can tell, but I think 1.9 should take precedence:

Program execution, 1.9 (6) and (7):

The observable behavior of the abstract machine is its sequence of reads and writes to volatile data and calls to library I/O functions.6)

Accessing an object designated by a volatile lvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression might produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.

And in 7.1.5.1:

[Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. See 1.9 for detailed semantics. In general, the semantics of volatile are intended to be the same in C++ as they are in C. ]

¹ That doesn't work with void fun(), of course.