CS412/413

1
CS412/413

• Introduction to
• Compilers and Translators
• Spring 99
• Lecture 14 Canonical Intermediate Code

2
Administration

• Prelim 1 on Monday in class
• topics covered regular expressions, tokenizing,
  context-free grammars, LL LR parsers, static
  semantics
• No class Wednesday
• Programming Assignment 2 due Friday
• Prelim review tomorrow (Saturday) 7-9 PM

3
Where we are
abstract syntax tree
translation functions
intermediate code
canonicalization
canonical intermediate code
code generation
assembly code
4
Why canonical form?

• Intermediate code has general tree form
• easy to generate from AST, but...
• Hard to translate directly to assembly
• assembly code is a sequence of statements
• Intermediate code has nodes corresponding to
  assembly statements deep in expression trees
• Canonical form all statements brought up to top
  level of tree -- can generate assembly directly

5
Statements

• Statements corresponding to assembly
• MOVE, JUMP, CJUMP, EXP(CALL(), MOVE(CALL(),),
  LABEL
• Extra constructs to make IR gen easier SEQ,
  ESEQ, CALL (as arbitrary expression)
• SEQ, ESEQ keep track of what order two statements
  (or a statement and an expression) are supposed
  to be evaluated in
• need to get rid of these and also move CALL
  expressions up to top under MOVE or EXP

6
Canonicalization
SEQ
SEQ
SEQ
SEQ
SEQ
SEQ
...
MOVE
JUMP
LABEL
EXP
...
...
CALL
CALL
7
Pulling statements up

• Cant have statement nodes under an expression
  node
• Can only occur because of ESEQ(s,e)
• For each expression node type, canonicalize
  transforms an expression e into statements (s1,
  s2, s3,) and a side-effect-free expression e
• Can implement recursively

8
Rewrite rules

• Canonicalize e e ? (s1, s2, s3,), e
• e ? (s1,, sm ), e
• ESEQ(s, e) ? (s, s1,, sm ), e
• e1 ? (s1,, sm), e1
• e2 ? (s1,, sn), e2
• (e1,e2) ? (s1,, sm, MOVE(e1,TEMP(t)), s1,,
  sn), (TEMP(t), e 2)
• e1 ? (s1,, sm), e1
• e2 ? (), e2
• (e1,e2) ? (s1,, sm), (e1, e 2)

9
CALL nodes

• CALL nodes call a function which may have side
  effects
• Overwrites return value register at least cant
  be operand at assembly-code level
• Therefore, CALL nodes must move to top
• Idea
• CALL( f, args) Þ
• (MOVE(CALL(f, args), TEMP(t)), TEMP(t)

10
Flattening SEQ nodes

• All SEQ nodes now top level or children only of
  SEQ nodes
• No ESEQ nodes -- all statement nodes are children
  of SEQ nodes
• All CALL nodes children of EXP nodes or MOVE
  nodes at top level
• Final step linearize SEQ nodes in-order

SEQ
...
SEQ
SEQ
SEQ
SEQ
SEQ
SEQ
s1 s2 s3 s4
s1
s2
s3
s4
11
Linearization rules

• ? for statements s ? (s1, s2, s3,)
• s1 ? (s1,sm )
• s2 ? (s1,, sn)
• SEQ(s1, s2) ? (s1,sm, s1,, sn)
• e1 ? (s1,sm ), e1
• e2 ? (s1,sn ), e2
• MOVE(e1, e2 ) ? (s1,sm , s1,sn , MOVE(e1 ,
  e2))

12
Flattened tree

• Two recursive transformations
• s ? (s1, s2, s3,)
• e ? (s1, s2, s3,), e
• Can be applied to any IR tree s
• Result a linear list of statements
• (s1, s2, s3,)
• All statements one of MOVE, JUMP, CJUMP,
  EXP(CALL(), MOVE(CALL(),), LABEL

13
Conditional jumps

• IR is now just a linear list of statements
• Still contains CJUMP nodes two-way branches
• Real machines fall-through branches (e.g. JZ,
  JNZ)

CJUMP e, t, f ... LABEL(t) if-true code LABEL(f)
evaluate e JZ f if-true code f
14
Basic blocks

• A basic block is a sequence of statements that is
  always begun at its start and always exits at the
  end
• starts with a LABEL(n) statement
• ends with a JUMP or CJUMP statement
• contains no other JUMP or CJUMP statement
• contains no interior LABEL that is used as the
  target for a JUMP or CJUMP from elsewhere

15
Fixing conditional jumps

• Reorder basic blocks so that (if possible)
• the false direction of two-way jumps goes to
  the very next block
• JUMPs go to the next block
• What if not satisfied?
• For CJUMP add another JUMP immediately after to
  go to the right basic block
• How to find such an ordering of the basic blocks?

16
Traces

• Idea order blocks according to a possible trace
  a sequence of blocks that might (naively) be
  executed in sequence, never visiting a block more
  than once
• Algorithm
• pick an unmarked block (begin w/ start block)
• run a trace until no more unmarked blocks can be
  visited, marking each block on arrival
• repeat until no more unmarked blocks

17
Example

• Possible traces?

18
Arranging by traces
1
1
2
4
5
3
2
3
2
4
4
5
5
3
19
Conclusions

• Simple code transformations (?) can transform the
  IR representation into a canonical form that is
  similar to assembly code.
• Get rid of ESEQ, SEQ nodes
• Move CALL to top level
• Convert to linear sequence of statements
• Make all CJUMPs one-way jumps by identifying,
  rearranging basic blocks.
• Result ready to generate assembly code!

20
Reminder

• Prelim 1 on Monday in class
• topics covered regular expressions, tokenizing,
  context-free grammars, LL LR parsers, static
  semantics
• No class Wednesday
• Programming Assignment 2 due Friday
• Prelim review tomorrow (Saturday) 7-9 PM