Selecting Software Phase Markers with Code Structure Analysis

2. Selecting Software Phase Markers with Code Structure Analysis Brad Calder UC San Diego

3. Introduction • Program behavior changes over time • Current behavior often very different from average behavior • Program’s have repetitive behavior based on how code is written • Many potential uses • Accelerated architecture simulation • Just simulate a single sampleof each program behavior • Dynamic reconfiguration • Target program’s currentbehavior instead of average behavior

4. Time Varying Behavior: gzip • Examine program behavior over entire program run • Discover periodic/repetitive behavior • Goal: Find stable (consistent) region of execution • Phases: periods of stable behavior • Phase Change: transition into stable behavior Time (Instructions Executed x 107)

5. Focus of Research • Identify phase change boundaries at procedure calls, returns and loops • Find transitions into stable regions • These locations identify “Software Phase Markers” • Insert the marker into the binary • Identifies the start of a phase when executed (what phase is coming next) • Perform the above analysis using Phoenix as a binary instrumentation profiling tool • Profile program to collect a hierarchicalcall-loop graph

6. Software Phase Markers • A Call-loop graph is just a hierarchical call graph with: • Extra nodes for loops • Extra nodes to represent recursion (loops and procedural) • Loops represented with loop head and loop body nodes. This identifies: • Loop Head - loops that are stable on each entry • Loop Body - loops that are stable on each iteration • Evaluate hierarchical stability of edges to identify stable regions of execution • Examine variance in hierarchical instruction for edges in Call-loop graph • We look at coefficient of variation: CoV = stddev / avg

7. An Example Proc foo() loop if (cond) call X; else call Y; end loop call X; end proc Proc X() call Z; end proc • Code segment on left, call-loop graph on right

8. Example Continued • Each edge is annotated with: • C = number of times each edge is traversed (call count) • A = average number of hierarchical instructions executed each time the edge is traversed • CoV = hierarchical instruction count coefficient of variation

9. Using Phoenix • Instrumentation Code • Uniquely identify each Call and Loop branch location • Profiler just has to perform an array index • Instrument each basic block to associate BB’s executed instructions with the current context • Instrument each Call/Ret and Loop branch edge • Also record line number information • Analysis Code • Keep track of a call-loop stack • Where to assign local and the hierarchical time

10. Phase Markers – gcc-166 • Map phase markets back to source code using Phoenix symbol information • Each phase marker is represented with a unique symbol • Most stable (repetitive) behaviors are uniquely marked • gcc-166 exhibits the same behavior pattern twice, and we see the same marker pattern twice

11. Summary • Use Phoenix to profile programs to find points in program that exhibit consistent regions (phases) of execution • These are software phase markers: • A lightweight way to indicate a change into a consisten region is about to occur • To find software phase markers: build a call-loop graph using Phoenix to find hierarchically stable edges • Currently • Applying to SimPoint to pick source code simulation points • Inserting into binary and examining its use to guide hardware (cache) reconfiguration