EE (CE) 6304 Computer Architecture Lecture #12 (10/25/17)

1. EE (CE) 6304 Computer ArchitectureLecture #12(10/25/17) Yiorgos Makris Professor Department of Electrical Engineering University of Texas at Dallas Course Web-site: http://www.utdallas.edu/~gxm112130/EE6304FA17

2. Branch Prediction

3. Stream of Instructions To Execute Instruction Fetch with Branch Prediction Out-Of-Order Execution Unit Correctness Feedback On Branch Results Independent “Fetch” unit • Instruction fetch decoupled from execution • Often issue logic (+ rename) included with Fetch

4. Branches must be resolved quickly • In our loop-unrolling example, we relied on the fact that branches were under control of “fast” integer unit in order to get overlap! • Loop: LD F0 0 R1 MULTD F4 F0 F2 SD F4 0 R1 SUBI R1 R1 #8 BNEZ R1 Loop • What happens if branch depends on result of multd?? • We completely lose all of our advantages! • Need to be able to “predict” branch outcome. • If we were to predict that branch was taken, this would be right most of the time. • Problem much worse for superscalar machines!

5. Relationship between precise interrupts and speculation: • Speculation is a form of guessing • Branch prediction, data prediction • If we speculate and are wrong, need to back up and restart execution to point at which we predicted incorrectly • This is exactly same as precise exceptions! • Branch prediction is very important! • Need to “take our best shot” at predicting branch direction. • If we issue multiple instructions per cycle, lose lots of potential instructions otherwise: • Consider 4 instructions per cycle • If take single cycle to decide on branch, waste from 4 - 7 instruction slots! • Technique for both precise interrupts/exceptions and speculation: in-order completion or commit • This is why reorder buffers in all new processors

6. Next fetch started PC Fetch I-cache Fetch Buffer Decode Issue Buffer Execute Func. Units Result Buffer Branchexecuted Commit Arch. State Control Flow Penalty Modern processors may have > 10 pipeline stages between next PC calculation and branch resolution ! How much work is lost if pipeline doesn’t follow correct instruction flow? ~ Loop length x pipeline width

7. After Reg. Fetch* *Assuming zero detect on register read MIPS Branches and Jumps Each instruction fetch depends on one or two pieces of information from the preceding instruction: 1) Is the preceding instruction a taken branch? 2) If so, what is the target address? Instruction Taken known? Target known? J JR BEQZ/BNEZ After Inst. Decode After Inst. Decode After Inst. Decode After Reg. Fetch After Inst. Decode

8. A PC Generation/Mux P Instruction Fetch Stage 1 F Branch Target Address Known Instruction Fetch Stage 2 B Branch Address Calc/Begin Decode I Complete Decode J Steer Instructions to Functional units Branch Direction & Jump Register Target Known R Register File Read E Integer Execute Remainder of execute pipeline (+ another 6 stages) Branch Penalties in Modern Pipelines UltraSPARC-III instruction fetch pipeline stages (in-order issue, 4-way superscalar, 750MHz, 2000)

9. Reducing Control Flow Penalty • Software solutions • Eliminate branches - loop unrolling • Increases the run length • Reduce resolution time - instruction scheduling • Compute the branch condition as early • as possible(of limited value) • Hardware solutions • Find something else to do - delay slots • Replaces pipeline bubbles with useful work • (requires software cooperation) • Speculate - branch prediction • Speculative execution of instructionsbeyond the branch

10. Branch Prediction • Motivation: • Branch penalties limit performance of deeply pipelined processors • Modern branch predictors have high accuracy:(>95%) and can reduce branch penalties significantly • Required hardware support: • Prediction structures: • Branch history tables, branch target buffers, etc. • Mispredict recovery mechanisms: • Keep result computation separate from commit • Kill instructions following branch in pipeline • Restore state to state following branch

11. Case for Branch Prediction when Issue N instructions per clock cycle • Branches will arrive up to n times faster in an n-issue processor • Amdahl’s Law => relative impact of the control stalls will be larger with the lower potential CPI in an n-issue processor • conversely, need branch prediction to ‘see’ potential parallelism • Performance = ƒ(accuracy, cost of misprediction) • Misprediction  Flush Reorder Buffer • Questions: How to increase accuracy or decrease cost of misprediction? • Decreasing cost of misprediction • Reduce number of pipeline stages before result known • Decrease number of instructions in pipeline • Both contraindicated in high issue-rate processors!

12. JZ JZ Static Branch Prediction Overall probability a branch is taken is ~60-70% but: backward 90% forward 50% • ISA can attach preferred direction semantics to branches, e.g., Motorola MC88110 • bne0 (preferred taken) beq0 (not taken) • ISA can allow arbitrary choice of statically predicted direction, e.g., HP PA-RISC, Intel IA-64 typically reported as ~80% accurate

13. Predicated Execution • Avoid branch prediction by turning branches into conditionally executed instructions: if (x) then A = B op C else NOP • If false, then neither store result nor cause exception • Expanded ISA of Alpha, MIPS, PowerPC, SPARC have conditional move; PA-RISC can annul any following instr. • IA-64: 64 1-bit condition fields selected so conditional execution of any instruction • This transformation is called “if-conversion” • Drawbacks to conditional instructions • Still takes a clock even if “annulled” • Stall if condition evaluated late • Complex conditions reduce effectiveness; condition becomes known late in pipeline x A = B op C

14. Dynamic Branch Predictionlearning based on past behavior • Temporal correlation • The way a branch resolves may be a good predictor of the way it will resolve at the next execution • Spatial correlation • Several branches may resolve in a highly correlated manner (a preferred path of execution)

15. Dynamic Branch Prediction Problem History Information • Incoming stream of addresses • Fast outgoing stream of predictions • Correction information returned from pipeline Branch Predictor Incoming Branches { Address } Prediction { Address, Value } Corrections { Address, Value }

16. What does history look like?E.g.: One-level Branch History Table (BHT) Predictor 0 Branch PC Predictor 1 • Each branch given its own predictor state machine • BHT is table of “Predictors” • Could be 1-bit, could be complex state machine • Indexed by PC address of Branch – without tags • Problem: in a loop, 1-bit BHT will cause two mispredictions (avg is 9 iterations before exit): • End of loop case: when it exits instead of looping as before • First time through loop on next time through code, when it predicts exit instead of looping • Thus, most schemes use at least 2 bit predictors • In Fetch state of branch: • Use Predictor to make prediction • When branch completes • Update corresponding Predictor Predictor 7

17. 2-bit predictor • Solution: 2-bit scheme where change prediction only if get misprediction twice: • Red: stop, not taken • Green: go, taken • Adds hysteresis to decision making process T NT Predict Taken Predict Taken T NT T NT Predict Not Taken Predict Not Taken T NT

18. Fetch PC 0 0 I-Cache k 2k-entry BHT, n bits/entry BHT Index Instruction Opcode offset + Branch? Taken/¬Taken? Target PC Typical Branch History Table 4K-entry BHT, 2 bits/entry, ~80-90% correct predictions

19. A PC Generation/Mux Correctly predicted taken branch penalty P Instruction Fetch Stage 1 F Instruction Fetch Stage 2 B Branch Address Calc/Begin Decode I Complete Decode Jump Register penalty J Steer Instructions to Functional units R Register File Read E Integer Execute Remainder of execute pipeline (+ another 6 stages) Pipeline considerations for BHT Only predicts branch direction. Therefore, cannot redirect fetch stream until after branch target is determined. UltraSPARC-III fetch pipeline

20. Branch Target Buffer predicted BPb target Branch Target Buffer (2k entries) IMEM k PC target BP BP bits are stored with the predicted target address. IF stage: If (BP=taken) then nPC=target else nPC=PC+4 later: check prediction, if wrong then kill the instruction and update BTB & BPb else update BPb

21. 132 Jump +100 Assume a 128-entry BTB 1028 Add ..... target BPb 236 take Instruction Memory Address Collisions in BTB What will be fetched after the instruction at 1028? BTB prediction = Correct target =  236 1032 kill PC=236 and fetch PC=1032 Is this a common occurrence? Can we avoid these bubbles?

22. BTB is only for Control Instructions BTB contains useful information for branch and jump instructions only  Do not update it for other instructions For all other instructions the next PC is PC+4 ! How to achieve this effect without decoding the instruction?

23. I-Cache PC Entry PC predicted Valid target PC k = match target valid Branch Target Buffer (BTB) 2k-entry direct-mapped BTB (can also be associative) • Keep both the branch PC and target PC in the BTB • PC+4 is fetched if match fails • Only predicted taken branches and jumps held in BTB • Next PC determined before branch fetched and decoded

24. 132 Jump +100 entry PC target BPb 1028 Add ..... 132 236 take Consulting BTB Before Decoding • The match for PC=1028 fails and 1028+4 is fetched •  eliminates false predictions after ALU instructions • BTB contains entries only for control transfer instructions •  more room to store branch targets

25. A PC Generation/Mux P Instruction Fetch Stage 1 BTB F Instruction Fetch Stage 2 BHT in later pipeline stage corrects when BTB misses a predicted taken branch B BHT Branch Address Calc/Begin Decode I Complete Decode J Steer Instructions to Functional units R Register File Read E Integer Execute BTB/BHT only updated after branch resolves in E stage Combining BTB and BHT • BTB entries are considerably more expensive than BHT, but can redirect fetches at earlier stage in pipeline and can accelerate indirect branches (JR) • BHT can hold many more entries and is more accurate

26. Uses of Jump Register (JR) BTB works well if same case used repeatedly • Switch statements (jump to address of matching case) • Dynamic function call (jump to run-time function address) • Subroutine returns (jump to return address) BTB works well if same function usually called, (e.g., in C++ programming, when objects have same type in virtual function call) BTB works well if usually return to the same place  Often one function called from many distinct call sites! How well does BTB work for each of these cases?

27. Pop return address when subroutine return decoded Push return address when function call executed k entries (typically k=8-16) Subroutine Return Stack Small structure to accelerate JR for subroutine returns, typically much more accurate than BTBs. fa() { fb(); nexta: } fb() { fc(); nextb: } fc() { fd(); nextc: } &nextc &nextb &nexta

28. Special Case Return Addresses • Register Indirect branch hard to predict address • SPEC89 85% such branches for procedure return • Since stack discipline for procedures, save return address in small buffer that acts like a stack: 8 to 16 entries has small miss rate Select for Indirect Jumps [ On Fetch ] Fetch Unit BTB PC Predicted Next PC Mux Destination From Call Instruction [ On Fetch?] Return Address Stack

29. Performance: Return Address Predictor • Cache most recent return addresses: • Call  Push a return address on stack • Return  Pop an address off stack & predict as new PC