Class 32: Intermediate code, concluded

Held Monday, November 23, 1998

Notes

• If you haven't already done so, please start to read chapter 9, which we may start today, and which we'll definitely start the Monday after break.
• Reminder: topics and dates for presentations are due Wednesday.
• On Wednesday, we'll talk about the interpreter for straight-line intermediate representation trees.
• Did anyone do or think about 8.5?
• As an exercise for next Monday, think about appropriate tree patterns for the ``straight-line IRTs''.
• I'm updating the code files ``on the fly'' as it were. Please knock on my door before copying one. (And check again for changes.)
  • I have a structuring question. My temptation is to write the complete irtframe.c and IRTFrame.java. However, these will necessarily rely on stuff you haven't written yet. Do you want different versions, for different stages of your compilers?

Another Canonicalization Example

• Let's do a few more examples of canonicalization. All are taken from Appel.
  • What do they do?
• Appel, exercise 8.2 a.

  MOVE(
    MEM(
      ESEQ(
        SEQ(
          CJUMP(
            LT,
            TEMP(i),
            CONST(0),
            L(out)
            L(ok)),
          LABEL(ok)),
        TEMP(i))),
    CONST(1))
  

• Appel, exercise 8.2 c.

  BINOP(
    PLUS,
    CALL(NAME(f), [TEMP(x)]),
    CALL(
      NAME(g),
      [ ESEQ(
          MOVE(TEMP(x), CONST(0)),
          TEMP(x)) ]))
  

Structuring Code

• Once we've carefully transformed our program fragments into a number of sequences of canonical trees, we still have some work left to do on our transition towards assembly code.
• We need to join the program fragments together.
• We need to give conditional branches a single label (in which case they branch when true and ``fall through'' when false).
• We'll solve both problems at once by pulling the code apart and then putting it back together.

Basic Blocks

• The key to all of this is to find basic blocks: sequences of statements that are always entered at the beginning and exited at the end.
• That is,
  • basic blocks contain at most one JUMP or CJUMP, and that falls at the end.
  • all JUMPs and CJUMPs in the program go to the beginning of the block (or to nowhere in the block).
• Note that it's safe to rearrange basic blocks (as long as you handle the ``fall through to next block'' case appropriately).
• We typically try to make basic blocks as large as possible. Hence, if a bunch of code doesn't end with a JUMP or CJUMP, and nothing jumps to the subsequent instruction (or sequence of instructions), then we can tie it all together in one basic block.
• Appel has a somewhat different definition of basic block.
  • The first statement is a label.
  • The last statement is a JUMP or CJUMP
  • There are no other labels, JUMPs, or CJUMPs.

Building Basic Blocks

• How do we identify the basic blocks in a program? It's easier than you might think.
• Scan the code from beginning to end.
• When you hit a label, begin a new block.
  • (Typically, we only insert labels when they are the destination of a JUMP or CJUMP, so it's best to assume that code can branch to the label.)
• When you hit a JUMP or CJUMP, end the current block and begin a new block.
  • JUMP and CJUMP can only appear at the end of the block.
• To match Appel's version, you'll also need to
  • Insert a new label at the beginning of any block that doesn't have a label.
  • Insert a JUMP next-block at the end of any block that doesn't have a JUMP or CJUMP at the end.
• For example, in

  MOVE alpha beta
  JUMP l123
  MOVE beta gamma
  

  we need to begin a new block after the JUMP, but it doesn't have a label. (It's arguable that it can never be executed, but we'll leave that as an issue for later.)
• Similarly, in

  MOVE alpha beta
  LABEL l432
  MOVE beta gamma
  

  we need to begin a new block starting with label l432, but the previous block "falls through" to block with label l432. We add a JUMP l432 so that we can successfully rearrange the blocks.

Joining Basic Blocks

• We can put the blocks in any order. What order should we use?
• In general, we want to put blocks after blocks that they naturally follow.
• For example, we'd like the false branch of conditional jumps to follow conditions. (If they don't, we'll need to do some cleanup in order to eliminate the false branch).
  • Similarly, we'd like the block with label l to follow a block that ends JUMP l.
• Appel suggests that we build a set of traces, natural sequences of blocks.
  • Ideally, we'd build traces that require the least amount of execution time (fewest jumps).
  • That's difficult (impossible) to determine.

History

• Created Friday, November 20, as a blank outline.
• On Monday, November 23, 1998, filled in the details.
• On Monday, November 30, 1998, moved a section to outline 34.