The "jump threading" compiler optimization (aka -fthread-jump) turns conditional into unconditional branches on certain paths at the expense of code size. For hardware with branch prediction, speculative execution, and prefetching, this can greatly improve performance. However, there is no scientific publication or documentation at all. The Wikipedia article is very short and incomplete.
The linked article has an illustrated treatment of common code structures and how these optimizations work.
(Score: 1) by Delwin on Monday November 02 2015, @10:44PM
Every function has overhead, so no. Even inline is only a suggestion to the compiler, not a hard requirement.
(Score: 2) by tibman on Tuesday November 03 2015, @02:51AM
Being readable and easier to maintain is better than saving on function overhead. If the compiler finds it is best to in-line some functions, let it do that. Unless you are dealing with an extremely resource constrained system.
SN won't survive on lurkers alone. Write comments.
(Score: 0) by Anonymous Coward on Tuesday November 03 2015, @03:59AM
Being readable and easier to maintain is better than saving on function overhead.
You can make readable and maintainable code with gotos. And even a system that isn't necessarily resource constrained doesn't deserve to be abused by sloppy coding. I know that more processing power means that programming think they can waste as many resources as possible, but I prefer not to.
(Score: 2) by tibman on Tuesday November 03 2015, @02:14PM
Removing duplicate code by putting it into a function is not a waste of resources. That is a major reason why functions exist. Doing the same with gotos is fine as well, i never said otherwise.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by Wootery on Tuesday November 03 2015, @11:24AM
Even inline is only a suggestion to the compiler, not a hard requirement.
Yes, because inlining everything isn't always a good thing for performance. Code size matters for cache behaviour, and function-calls/returns are cheap on modern CPUs. The compiler probably knows better than you whether inlining makes sense or not.
But none of that matters. Readability is generally far more important than tiny potential performance differences.