Though in general it is true that you should simply leave C code optimization to the compiler, it sometimes is useful to provide hints to the compiler. This is because when optimizing the compiler has to make a few basic global assumptions so as to generate correct code in all situations, but these assumptions may not be true in your specific code.

A case in point is providing aliasing hints through the use of the C99 restrict keyword or the GCC extension __restrict__. See this excellent article with an easy example that will help you understand aliasing and how to deal with it.

It seems obvious that if you have multiple else-if clauses, then putting the most likely to execute code in the first if clause would be the best (since it avoids subsequent checks most of the time), but what about the case that you only have a two-way if (cond) {…} else {…}  type of code, should you place the code most likely to be executed in the if clause or in the else clause? It would seem that it shouldn’t matter either way since there is only one condition being checked. But…

I did some experimentation on a system at hand (an Intel Pentium system with a small program compiled using gcc) and found that putting the most likely to be executed code as part of the else clause consistently had better timings. Be warned that this was just a simplistic “add-two-values-stored-in-variables-in-one-line” kind of code — definitely not a good test, but sufficient for me to satisfy my curiousity for the time being.

Google searching seemed to indicate that the performance depended on the ‘branch prediction‘ capability of the processor. I also found out that gcc has a compiler directive (__builtin_expect()) that one can use to provide a hint to the compiler so it knows what is the most likely outcome of a if conditional check and generate code suitable for the branch prediction capability of the target processor. The gcc manual recommends against using this directive though! See more details regarding this directive here.