Sentinel Scheduling

1. Sentinel Scheduling Multimedia Systems Lab. 2006년 5월 17일 김경환

2. OUTLINE • Necessity of Sentinel Scheduling • Sentinel Scheduling Design • Sentinel Scheduling Algorithm • How to generate recovery code • Summary

3. Necessity of Sentinel Scheduling • Needs of Speculation • ILP is necessary in VLIW and Superscalar architectures • Insufficient ILP within basic blocks (especially for non-numeric applications) • Instruction scheduling across basic block boundaries is need • Benefits of Speculation • Increase ILP (break control dependencies) • Tolerate latencies (issue long-latency instruction earlier) • Increase loop-level parallelism

4. Necessity of Sentinel Scheduling • Problem of Speculation • Speculated instructions may raise exceptions • Code often contains tests to prevent exceptions (divide by zero) • What instructions make exception? • How can handle exceptions?

5. Necessity of Sentinel Scheduling • only some instructions can cause exceptions (PEI’s) • PEI : potentially excepting instructions • Cause of Exceptions • Memory operations (segmentation fault, null exception) • Divide operations (divide by zero) • Any floating-point operation (NaN) • Other operations can be speculatively scheduled without worrying about exceptions

6. Necessity of Sentinel Scheduling • Method for exception processing • Approach A – only allow speculative code motion on instructions that do not cause exception → too restrictive ILP • Approach B – hardware support→ hardware cost • Four Implementations • Restricted Percolation • General Percolation • Instruction Boosting • Sentinel Scheduling

7. Necessity of Sentinel Scheduling • Restricted Percolation Software-only speculation. Complier is allowed to move instructions above branches only if they never cause exceptions and the compiler can find a destination for the operation that isn’t used in the other path.

8. Necessity of Sentinel Scheduling • General Percolation • Hardware must implement silent (non-faulting) verions of all PEIs • Speculate PEIs by replacing with silent versions • Downside : exceptions in speculative ops may never be detected.

9. Necessity of Sentinel Scheduling

10. Necessity of Sentinel Scheduling • Pros • Low hardware cost • Allows more speculation than restricted percolations • Cons • Writing garbage into dest register makes bugs harder to find • Some exceptions may never get caught

11. Necessity of Sentinel Scheduling • Instruction Boosting • Scheduler not responsible for dealing with exceptions or preventing state modifications. • Add hardware to deal with speculation issues • Shadow register file buffers instruction results • Shadow store buffers hold data from store instructions • When speculative instructions execute, their results go into shadow register file and shadow store buffer. • Speculating results commit into memory, register file when their associated branch completes.

12. Necessity of Sentinel Scheduling

13. Necessity of Sentinel Scheduling • pros • Allows more instructions to be speculated • Good exception recovery • cons • Big hardware cost • Bypassing may increase cycle time

14. Necessity of Sentinel Scheduling • From Instruction boosting • provide an effective framework for speculative code motion of instrs. and identification of exceptions • From general percolation • lower hardware implementation cost → Sentinel Scheduling

15. Sentinel Scheduling Design • Design Objectives • Correctly ignore exceptions generated by speculative whose execution turns out to be unnecessary • Correctly report exceptions generated by speculative instrs. • Support recovery from exceptions thus reported • Minimize the hardware cost • What’s the sentinel

16. Sentinel Scheduling Design What’s the watching object? What can be a sentinel?

17. Sentinel Scheduling Design • Watching object ? • Exception of speculative instructions • Sentinel ? • any non-speculative inst that read the destination of a speculative instruction is a sentinel for that inst • If no such inst exists, need to add an explicit sentinel inst

18. Sentinel Scheduling Design • Key observation : Instructions have two functions • Perform Operation • Detect Exception • Architectural Support • One bit in each opcode records whether the instruction is speculative • Each register contains two additional fields • Exception flag • Exception PC

19. Sentinel Scheduling Design • Each instruction has sentinel part to detect exception • Sentinel part elimination • If there is another inst in inst’s home block which uses the result of inst • Home block : The home block is the basic block thatcontained the instruction before it was made speculative • I is non-excepting and is not the last direct or indirect use of an excepting instruction’s destination

20. Sentinel Scheduling Algorithm • Algorithm • Identify unprotected instructions - unprotected instruction : an inst whose sentinel cannot be eliminated • Perform conventional scheduling • If an unprotected instruction is moved above a branch, a sentinel is placed in the place where the instructions were moved speculatively • When a speculative instruction causes an exception, the exception flag is set and its current PC is saved • When the sentinel is executed, the exception flag is checked and an exception is taken

21. Sentinel Scheduling Algorithm • Exception Model : Speculative instructions • src(I).except = 0 • I does not cause an exception • Normal execution • I causes an exception • dest(I).except = 1 • dest(I).data = pc of I • src(I).except = 1 • Exception propagation • dest(I).except = 1 • dest(I).data = src(I).data

22. Sentinel Scheduling Algorithm • Exception Model : Non-Speculative instructions • src(I).except = 0 • I does not cause an exception - Normal execution • I causes an exception - I reported as source of exception • src(I).except = 1 • Report exception for speculative instruction • Signal exception • dest(I).data if PC of exception

23. Sentinel Scheduling Algorithm • Scheduling Constraints • Compiler is responsible for ensuring speculative insts don’t overwrite registers needed on the other path of the branch • Compiler must ensure that every speculative instrs has a sentinel inst in its home block • Source operations of speculative instructions may not be overwritten until the sentinel for that instruction executes.

24. Sentinel Scheduling Algorithm

25. Sentinel Scheduling Algorithm

26. Sentinel Scheduling Algorithm

27. Sentinel Scheduling Algorithm

28. How to generate recovery code • PEI’s flow dependence chain • It is the chain of instructions which are flow dependent on the PEI • The first instruction is flow dependent on the PEI, the second instruction is flow dependent on the first instruction,… • The flow dependence chain stops at a sentinel • Usage of PEI’s flow dependence chain • If an explicit check is needed or not • Make recovery code

29. How to generate recovery code • Code Example

30. How to generate recovery code • PEI’s flow dependence chain • An instruction can act as an implicit check for a PEI if it is flow dependent on an instruction located in the PEI’s flow dependence chain and is not speculated • If there is no istruction in a PEI’s home block that meets this criteria, an explicit check must get added I3 I2 I5 I4 I5 I6

31. How to generate recovery code • How to generate recovery code • The instructions put into the recovery block consist of all the PEI’s from a home block • All the speculated instructions found in the PEI’s flow dependent chains • At the end of the recovery block, a return operations is inserted

32. Summary • Sentinel Scheduling • Correctly ignore exceptions generated by speculative whose execution turns out to be unnecessary • Correctly report exceptions generated by speculative instrs. • Generate recovery code • Minimize the hardware cost • Thank you