Class 35: Liveness analysis

Held Wednesday, December 2, 1998

Handouts

Notes

• Happy Birthday Kevin! We may have a small celebration in class on Friday (provided I get my act together).
• Sarah S's Exco class is demonstrating their projects in the forum, starting tomorrow.
• Reminder: to get credit for attending Clif Flynt's stuff, you need to send me email. I need it ASAP!
• I'm still working on coding. I hope to have everything ready for Friday, but I'm not sure I'll make it.
• I'll hand out fr
• Today from 7:30-8:30 p.m. and Thursday from 7:00 to 8:00 p.m., the department will be hosting a forum on changes to the Mathematics Major and upper level courses. You are welcome to attend. Let me know if you'd like a document summarizing the changes.
• On Thursday at 4:30, Professor James Broffitt, chair of the University of Iowa's Department of Statistics and Actuarial Science on Credibility and Batting Averages, which describes a technique called credibility or shrinkage estimation for combining data from several populations to estimate the mean for the population. The technique has applications in many areas, including actuarial science and baseball.
• Please read chapter 11 for Friday. You can ignore the part on "What to do for the Tiger compiler". You may need to read chapter 12 to finish your project, but we probably won't cover it in class.
• You all seem to know your assigned times and topics, so I won't make the mistake of misstating them again.
• Next Monday at noon, Tony Stubblebine will discuss Perl and CGI.
• I've finally updated the syllabus.

Context

• We now know how to generate something fairly close to assembly code (differing only from assembly code in its infinite use of registers).
• Where might we go from here?
  • We need to go from a large number of registers to a smaller number of registers.
  • We might want to improve memory usage.
  • We might want to improve the code.
• In going to a smaller number of registers, we may need to temporarily store some registers in memory and load them later.
• We can ground some of this choice by understanding when and how long registers are needed.
• Generalizing, we need to understand how long variables remain active in a program.
• Today, we'll look at liveness analysis: how one figures out how long a variable is needed within a prgram.
• On Friday, we'll look at register allocation.

Liveness analysis

• We can save space in memory and registers if we can determine when two ``variables'' are not used at the same time.
  • If both variables are stored in registers, we only need one register for the two.
  • If both variables are stored in memory, we only need one memory location for the two.
  • If one variable is stored in memory and the other in a register, we can safely use the memory location to store the register when it needs to be ``swapped out''.
• To do this type of analysis, we need to define ``used'', ``needed'', or ``live'' for variables.
  • The key attribute we care about is ``Do we need to remember the value assigned to this variable for later statements.''
  • It turns out that it is theoretically impossible to answer that question for an arbitrary program (this relates to the halting problem).
  • We will instead say ``Is it possible, in some path through the program, that the current value assigned to this variable will be used in a later statement?''
  • A variable that has this property is live.
• Note that liveness analysis can also be used for other compiler optimizations.
  • If we know that no variables are used after a recursive function call, we may be more able to do tail recursion removal.
  • If we know that a variable is used/needed before it is defined, then we can report an error (as Java does).
  • If we know that a variable is never used after it is defined, then we can discard the statement that defines it.

Theory

• We'll look at liveness in terms of relationships between statements.
• Note that there are two kinds of liveness for variables: a variable may be needed before the statement (Appel calls this ``in'') or after the statement (Appel calls this ``out'').
• We'll work in terms of sets:
  • in: the variables needed/live just before the statement;
  • out: the variables needed/live after the statement;
  • use: the variables used within the statement;
  • def: the variables defined by the statement;
  • succ: the successors of a statement; and
  • pred: the predecessors of a statement.
• We note that a variable is needed by a statement if it is used by that statement.
  • use(x) is a subset of in(x)
• We note that a variable is needed after a statement if it is needed in any subsequent statements.
  • out(x) is a superset of in(y) for each y that can follow x.
• We note that a variable is needed at the beginning of a statement if it is used after the statement and not defined in the statement.
  • in(x) is a superset of out(x)-def(x).
• There are no other times that variables are needed.
• Putting it together

  in(x) = use(x) union (out(x)-def(x))
  out(x) = { v in in(y) | y in succ(x) }
  

• In the abstract, we want to solve these mutually recursive equations.
• It turns out that there are many possible solutions. Consider the program

  s0: a := 0
  s1: a := b + c
  s2: b := a
  s3: end
  

• Then

  use(s0) = { }
  use(s1) = { b, c }
  use(s2) = { a }
  use(s3) = { }
  def(s0) = { a }
  def(s1) = { a }
  def(s2) = { b }
  def(s3) = { }
  succ(s0) = { s1 }
  succ(s1) = { s2 }
  succ(s2) = { s3 }
  succ(s3) = { }
  

• What definitions of in and out satisfy the equations given earlier?
  • Many
• Here's a solution that uses a few new variables. It may look a little odd, but you'll see that it satisifies the equations.

  in(s0) = { q,b,c }
  out(s0) = { q,b,c }
  in(s1) = { q,b,c }
  out(s1) = { q,a,b,c }
  in(s2) = { q,a,c }
  out(s2) = { q,a,b,c }
  in(s3) = { q,a,b,c }
  

• Here's a more compact solution

  in(s0) = { b,c }
  out(s0) = { b,c }
  in(s1) = { b,c }
  out(s1) = { a }
  in(s2) = { a }
  out(s2) = { }
  in(s3) = { }
  

• Given the possibility of multiple (in fact, infinite) solutions to the equations, how do we choose one?
  • We choose the smallest one. This is typically called the least fixed point of the equations.
  • We use an algorithm that builds the smallest one.

Practice

• What algorithm might we use to compute in and out?
• It turns out that a relatively straightforward one will work

  computed used and def for each statement 
    // the prior step is typically done during translation
  foreach statement, s
    in(s) = used(s)
  repeat
    foreach statement s
      in(s) = in(s) + (out(s)-def(s))
      foreach predecessor, p, of s
        out(s) = out(s) + in(p)
  until no changes are made
  

• We'll run this algorithm on some sample code

History

• Created Wednesday, November 25, 1998, as a blank outline.
• Filled in details on Wednesday, December 2.