Let's pretend for the moment that well predicted branches have zero cost and that all the code we need is ready in the instruction cache... If this were true, would we still want to eliminate branches? Yes. Not only are there the general overhead and scheduling costs to branches, but we cannot depend on the compiler to emit optimal-enough code when dealing with conditional expressions. Let's take a look at a simple example: Pretty straightforward. We're testing a couple of bits in the arguments to decide which argument we want to return. I want to point out that this example is particularly easy to handle because the C short-circuiting rules do not apply here. The compiler is free to do both tests on either side of the OR because (it can be trivially found) that there are no side-effects. Let's look at the compiler output (I've added some comments): Aside: Note that the stack pointer (sp) is being pushed and popped although the stack isn't being used in this function. Presumably, a function this small would be inlined so that would not occur. BTW, the -fomit-frame-pointer flag is ignored, if you're thinking that would help... I'm going to remove the stack push/pop code from any compiler output from this point on, unless the stack is actually being used. We'll assume the functions are inlined and that if they aren't you are aware of this cost. First notice the static branch prediction: (Syntax note: "-" added to a branch instruction indicates it is unlikely. Conversely, "+" indicates a likely branch.) It's unlikely that we will return arg0 because of the first test, but it is also unlikely that we will return arg1 due to the second test. Which means that it is unlikely this function will be fast. i.e. The compiler has decided that the most likely scenario is that the first test fails and the second test succeeds. Was that what you expected? The and with arg0 is pretty interesting too: "andis." means and with 16 bit immediate and shift, then update CR[0] -- The dot at the end of an instruction means "then update CR[0]". It's that dot that we should be concerned about. The CR is a very limited resource (32 bits = 8 x 4 bits) shared by all the execution units. Note the register moves: A lot of moves ("mr" means move register) among registers is usually a good indication of some kind of optimization barrior. Seeing three moves in such a short instruction stream is a good hint that something needs fixing. What we want: the whole test should be unlikely Following the logic that branches should be assumed not taken, we want to make it as simple as possible for the compiler to understand what we want. We can do this fairly easily by combining our comparison operations and only testing a single value. Here's the change: There is absolutely no possible way for the compiler to generate more than one branch in this scenario. We are only testing one value. The rest is simple bit operations. Can't be anything else. Really. Are you convinced yet? :) Take a look at the output: Pretty much what you expected right? The branch not-taken is unlikely. Everything is looking up. But did you see the "or." coming? That's right, the compiler's trying to be tricky and use the result of the or to determine the test value instead of doing a separate test. Again, prefer instruction sequences that do not modify or read the Condition Register. How can we reduce the dependencies on the Condition Register? Let me give you a hint. Here's the answer. And the final output: We'll go over how that works and why it works so much better in Part 3...