CS6290 Speculation Recovery

  • View
    37

  • Download
    0

Embed Size (px)

DESCRIPTION

CS6290 Speculation Recovery. Loose Ends. Up to now: Techniques for handling register dependencies Register renaming for WAR, WAW Tomasulos algorithm for scheduling RAW Branch prediction for control dependencies Still need to address: Memory dependencies Mispredictions, Faults, Exceptions. - PowerPoint PPT Presentation

Transcript

  • CS6290Speculation Recovery

  • Loose EndsUp to now:Techniques for handling register dependenciesRegister renaming for WAR, WAWTomasulos algorithm for scheduling RAWBranch prediction for control dependencies

    Still need to address:Memory dependenciesMispredictions, Faults, Exceptions

  • Speculative Fetch/Non-Spec ExecFetch instructions, even fetch past a branch, but dont exec right awayfetchdecodeissueexecwritecommit1. DIV R1 = R2 / R32. ADD R4 = R5 + R63. BEQZ R1, foo4. SUB R5 = R4 R35. MUL R7 = R5 * R26. MUL R8 = R7 * R3IEWC

  • Branch Prediction/Speculative ExecutionWhen we hit a branch, guess if its T or NTADDBranchABCDQRTNTGuess TSometime later, if we messed upKeep scheduling and executinginstructions as we knew theoutcome was TJust throw it all outAnd fetch the correct instructions

  • Again, with Speculative ExecutionAssume fetched direction is correctfetchdecodeissueexecwritecommit1. DIV R1 = R2 / R32. ADD R4 = R5 + R63. BEQZ R1, foo4. SUB R5 = R4 R35. MUL R7 = R5 * R26. MUL R8 = R7 * R3IEWC

  • Branch Misprediction RecoverybrARFRATARF state corresponds to state priorto oldest non-committed instructionAs instructions are processed, the RAT corresponds to the register mapping afterthe most recently renamed instructionOn a branch misprediction, wrong-pathinstructions are flushed from the machine?!?The RAT is left with an invalid set ofmappings corresponding to the wrong-path instruction state

  • Solution 1: Stall and DrainbrARFRAT?!?Correct path instructions from fetch;cant rename because RAT is wrongXARF now corresponds to the stateright before the next instruction tobe renamed (foo)Allow all instructions to execute andcommit; ARF corresponds to lastcommitted instructionReset RAT so that all mappingsrefer to the ARFResume renaming the new correct-path instructions from fetchPros: Very simpleto implementCons: Performance lossdue to stalls

  • Solution 2: CheckpointingbrbrbrbrARFRATAt each branch, make a copy of the RAT(register mapping at the time of the branch)RATRATRATRATOn a misprediction:CheckpointFree Pool1. flush wrong-path instructions2. deallocate RAT checkpoints3. recover RAT from checkpoint4. resume renaming

  • Speculative Execution is OKROB maintains program orderROB temporarily stores resultsIf we screw something up, only the ROB knows, but no architected state is affectedRegister rename recovery makes sure we resume with correct register mappingIf we mess up, we:

    Can undo the effectsKnow how to resume

  • Commit, ExceptionsWhat happens if a speculatively executed instruction faults?ABCDEA, B CommitDivide by Zero!Outside world sees: A, B, fault!Should have been: A, B, C, D, fault!ABCDEDivide by Zero!Branch mispredWXFault should never have happened!

  • Treat Fault Like a ResultRegular register results written to ROB untilInstruction is oldest for in-order state updateInstruction is known to be non-speculative

    Do the same with faults!At exec, make note of any faults, but dont expose to outside worldIf the instruction gets to commit, then expose the fault

  • ExampleFault deferred until architecturally correct point.Other fault never happenedABCDELOAD R6 = 0[R7]LOADP1LOAD R1 = 0[R2]ADD R3 = R1 + R4SUB R1 = R5 R6DIV R4 = R7 / R1ADDP2SUBP3DIVP4LOADP5immP1R5R7immR2R4R6P3R7ECFXXXXXMissXXFault!XXDivide by zeroResolvedXX(commit)X(3 commits)Now raise faultFlush rest of ROB,Start fetchingFault handler

  • Executing Memory InstructionsIf R1 != R7, then Load R8 gets correct value from cacheIf R1 == R7, then Load R8 should have gotten value from the Store, but it didnt!Load R3 = 0[R6]Add R7 = R3 + R9Store R4 0[R7]Sub R1 = R1 R2Load R8 = 0[R1]Cache Miss!Cache Hit!Miss servicedBut there was a later load

  • Out-of-Order Load ExecutionSo dont let loads execute out-of-order!ACBDGEFHILP = 8/3 = 2.67Ok, maybe not a goodidea. No support forOOO load executioncan reduce your ILP

  • What Else Could Happen?ABfoobarD$No problem.No problem.Uh oh.Uh oh.Should haveused Bsstore valueUh oh.Luckily, thisusually canteven happen

  • Memory Disambiguation ProblemWhy cant this happen with non-memory insts?Operand specifiers in non-memory insts are absoluteR1 refers to one specific locationOperand specifiers in memory insts are ambiguousR1 refers to a memory location specified by the value of R1. As pointers change, so does this location.

  • Two ProblemsMemory disambiguationAre there any earlier unexecuted stores to the same address as myself? (Im a load)Binary question: answer is yes or no

    Store-to-load forwarding problemWhich earlier store do I get my value from? (Im a load)Which later load(s) do I forward my value to? (Im a store)Non-binary question: answer is one or more instruction identifiers

  • Load Store Queue (LSQ)L0xF048417730x329042L/SPCSeqAddrValueS0xF04C417740x341025S0xF054417750x3290-17L0xF060417760x34181234L0xF840417770x3290-17L0xF858417780x33001S0xF85C417790x32900L0xF870417800x341025L0xF628417810x32900L0xF63C417820x33001Youngest0x3290420x3410380x341812340x33001Data Cache25-17Disambiguation: loads cannotexecute until all earlier storeaddresses computedForwarding: broadcast/searchentire LSQ for match

    Executed, completed, faulted