Event Name Goes Here

1
(No Transcript)
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
• Programs have repetitive behavior based on how
  code is written
• Many potential uses
• Accelerated architecture simulation
• Just simulate a single sample of each program
  behavior
• Dynamic reconfiguration
• Target programs current behavior 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 hierarchical
  call-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 BBs
  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