Editing Instruction pipelining (section)

===Branches===
A branch out of the normal instruction sequence often involves a hazard. Unless the processor can give effect to the branch in a single time cycle, the pipeline will continue fetching instructions sequentially. Such instructions cannot be allowed to take effect because the programmer has diverted control to another part of the program.

A conditional branch is even more problematic. The processor may or may not branch, depending on a calculation that has not yet occurred. Various processors may stall, may attempt [[branch prediction]], and may be able to begin to execute two different program sequences ([[Speculative execution#Eager execution|eager execution]]), each assuming the branch is or is not taken, discarding all work that pertains to the incorrect guess.{{efn|Early pipelined processors without any of these heuristics, such as the [[PA-RISC]] processor of [[Hewlett-Packard]], dealt with hazards by simply warning the programmer; in this case, that one or more instructions following the branch would be executed whether or not the branch was taken. This could be useful; for instance, after computing a number in a register, a conditional branch could be followed by loading into the register a value more useful to subsequent computations in both the branch and the non-branch case.}}

A processor with an implementation of branch prediction that usually makes correct predictions can minimize the performance penalty from branching. However, if branches are predicted poorly, it may create more work for the processor, such as [[pipeline flush|flushing from the pipeline]] the incorrect code path that has begun execution before resuming execution at the correct location.

Programs written for a pipelined processor deliberately avoid branching to minimize possible loss of speed. For example, the programmer can handle the usual case with sequential execution and branch only on detecting unusual cases. Using programs such as [[gcov]] to analyze [[code coverage]] lets the programmer measure how often particular branches are actually executed and gain insight with which to optimize the code.
In some cases, a programmer can handle both the usual case and unusual case with [[branch (computer science)#Branch-free code|branch-free code]].