Generation
CS Code 540 George Mason University
Compiler Architecture
Intermediate Language Source language Intermediate Language
Scanner (lexical analysis)
tokens
Parser (syntax analysis)
Syntactic structure
Semantic Analysis (IC generator)
Code Optimizer
Code Generator
Target language
Symbol Table
CS 540 Spring 2009 GMU 2
Code Generation
The code generation problem is the task of mapping intermediate code to machine code. Machine Dependent Optimization! Requirements: Correctness Efficiency
CS 540 Spring 2009 GMU 3
Issues:
Input language: intermediate code (optimized or not) Target architecture: must be well understood Interplay between
Instruction Selection Register Allocation Instruction Scheduling
CS 540 Spring 2009 GMU 4
Instruction Selection
There may be a large number of candidate machine instructions for a given IC instruction
each has own cost and constraints cost may be influenced by surrounding context different architectures have different needs that must be considered: speed, power constraints, space
CS 540 Spring 2009 GMU 5
Instruction Scheduling
Choosing the order of instructions to best utilize resources Architecture
RISC (pipeline) Vector processing Superscalar and VLIW
Memory hierarchy
Ordering to decrease memory fetching Latency tolerance doing something when data does have to be fetched
CS 540 Spring 2009 GMU 6
Register Allocation
How to best use the bounded number of registers. Complications:
special purpose registers operators requiring multiple registers.
CS 540 Spring 2009 GMU
7
Nave Approach to Code Generation
Simple code generation algorithm:
Define a target code sequence to each intermediate code statement type.
This is basically what we did earlier when creating the intermediate code (i.e. SPIM in project 3) Why is this not sufficient?
CS 540 Spring 2009 GMU
8
Example Target: SPIM Assembly Language
General Characteristics Byte-addressable with 4-byte words N general -purpose registers Three-address instructions: op destination, source1, source2
CS 540 Spring 2009 GMU
9
Mapping from Intermediate code
Simple code generation algorithm:
Define a target code sequence to each intermediate code statement type. Intermediate becomes
a := b lw $t0,b sw $t0,a
Intermediate becomes
a := b + c lw $t0,b lw $t1,c add $t0,$t0,$t1 sw $t0,a la $t0,a lw $t1,b add $t0,$t0,$t1 lw $t1,c sw $t1,($t0)
10
a := b[c]
la $t0,b a[b] := c lw $t1,c add $t0,$t0,$t1 lw $t0,($t0) sw $t0,a
CS 540 Spring 2009 GMU
Consider the C statement: a[i] = d[c[k]];
t1 := c[k]
la $t0,c lw $t1,k add $t0,$t0,$t1 lw $t0,($t0) sw $t0,t1 la $t0,d lw $t1,t1 add $t0,$t0,$t1 lw $t0,($t0) sw $t0,t2 la $t0,a lw $t1,i add $t0,$t0,$t1 lw $t1,t2 sw $t1,($t0)
t2 := d[t1]
a[i] := t2
We use 15 instructions (12 load/store + 3 arithmetic) and allocate space for two temporaries (but only use two registers).
CS 540 Spring 2009 GMU
11
Problems with this approach
Local decisions do not produce good code. Does not take temporary variables into account Get rid of the temporaries (reduce load/store):
la $t0,c lw $t1,k add $t0,$t0,$t1 # address of c[k] lw $t0,($t0) la $t1,d add $t1,$t1,$t0 # address of d[c[k]] lw $t1,($t1) la $t0,a lw $t2,i add $t0,$t0,$t2 # address of a[i] sw $t1,($t0)
CS 540 Spring 2009 GMU 12
Need a way to generate machine code based on past and future use of the data. Analyze the code Use results of analysis
CS 540 Spring 2009 GMU
13
Representing Intermediate Code: Control Flow Graph - CFG
CFG = < V, E, Entry >, where
V = vertices or nodes, representing an instruction or basic block (group of statements). E = (V x V) edges, potential flow of control Entry is an element of V, the unique program entry
1 2 3
CS 540 Spring 2009 GMU
4
5
14
Basic Blocks
A basic block is a sequence of consecutive statements with single entry/single exit:
flow of control only enters at the beginning Flow of control only leaves at the end Variants: single entry/multiple exit, multiple entry/single exit
CS 540 Spring 2009 GMU
15
Generating CFGs from Intermediate Code
Partition intermediate code into basic blocks Add edges corresponding to control flow between blocks
Unconditional goto Conditional goto multiple edges No goto at end control passes to first statement of next block
CS 540 Spring 2009 GMU 16
Partitioning into basic blocks
Input: A sequence of intermediate code statements 1. Determine the leaders, the first statements of basic blocks.
The first statement in the sequence is a leader. Any statement that is the target of a goto (conditional or unconditional) is a leader. Any statement immediately following a goto (conditional or unconditional) is a leader.
2. For each leader, its basic block is the leader and all statements up to, but not including, the next leader or the end of the program.
CS 540 Spring 2009 GMU 17
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15)
i := m 1 j := n t1 := 4 * n v := a[t1] i := i + 1 t2 := 4 * i t3 := a[t2] if t3 < v goto (5) j := j - 1 t4 := 4 * j t5 := a[t4] If t5 > v goto (9) if i >= j goto (23) t6 := 4*i x := a[t6]
(16) (17) (18) (19) (20) (21) (22) (23) (24) (25) (26) (27) (28) (29) (30)
t7 := 4 * i t8 := 4 * j t9 := a[t8] a[t7] := t9 t10 := 4 * j a[t10] := x goto (5) t11 := 4 * i x := a[t11] t12 := 4 * i t13 := 4 * n t14 := a[t13] a[t12] := t14 t15 := 4 * n a[t15] := x
18
CS 540 Spring 2009 GMU
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15)
i := m 1 j := n t1 := 4 * n v := a[t1] i := i + 1 t2 := 4 * i t3 := a[t2] if t3 < v goto (5) j := j - 1 t4 := 4 * j t5 := a[t4] If t5 > v goto (9) if i >= j goto (23) t6 := 4*i x := a[t6]
(16) (17) (18) (19) (20) (21) (22) (23) (24) (25) (26) (27) (28) (29) (30)
t7 := 4 * i t8 := 4 * j t9 := a[t8] a[t7] := t9 t10 := 4 * j a[t10] := x goto (5) t11 := 4 * i x := a[t11] t12 := 4 * i t13 := 4 * n t14 := a[t13] a[t12] := t14 t15 := 4 * n a[t15] := x
19
CS 540 Spring 2009 GMU
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15)
i := m 1 j := n t1 := 4 * n v := a[t1] i := i + 1 t2 := 4 * i t3 := a[t2] if t3 < v goto (5) j := j - 1 t4 := 4 * j t5 := a[t4] If t5 > v goto (9) if i >= j goto (23) t6 := 4*i x := a[t6]
(16) (17) (18) (19) (20) (21) (22) (23) (24) (25) (26) (27) (28) (29) (30)
t7 := 4 * i t8 := 4 * j t9 := a[t8] a[t7] := t9 t10 := 4 * j a[t10] := x goto (5) t11 := 4 * i x := a[t11] t12 := 4 * i t13 := 4 * n t14 := a[t13] a[t12] := t14 t15 := 4 * n a[t15] := x
20
CS 540 Spring 2009 GMU
Instruction Scheduling
Choosing the order of instructions to best utilize resources (CPU, registers, ) Consider RISC pipeline Architecture:
IF ID IF EX MA WB ID EX MA WB IF ID EX MA WB IF Instruction Fetch ID Instruction Decode EX Execute MA Memory access WB Write back
time
CS 540 Spring 2009 GMU
21
Hazards
1. Structural hazards machine resources limit overlap 2. Data hazards output of instruction needed by later instruction 3. Control hazards branching Pipeline stalls!
CS 540 Spring 2009 GMU 22
Data Hazards
Memory latency:
lw R1,0(R2) add R3,R1,R4
IF
ID IF
EX MA WB ID stall EX MA WB
Cant add until register R1 is loaded.
CS 540 Spring 2009 GMU
23
Data Hazards
Instruction latency:
addf R3,R1,R2 addf R3,R3,R4 IF ID IF EX EX MA WB
ID stall EX EX MA WB
Assumes floating point ops take 2 execute cycles
CS 540 Spring 2009 GMU
24
Dealing with Data Hazards
Typical solution is to re-order statements. To do this without changing the outcome, need to understand the relationship (dependences) between statements.
addf R3,R1,R2 add R5,R5,R6 addf R3,R3,R4 IF ID IF EX EX ID EX IF ID MA WB MA WB EX EX MA WB
25
CS 540 Spring 2009 GMU
Instruction Scheduling
Many operations have non-zero latencies Execution time is order-dependent Assumed latencies (conservative)
Operation load store loadI add mult fadd fmult shift branch Cycles 3 3 1 1 2 1 2 1 0 to 8
Loads & stores may or may not block
Scheduler should hide the latencies
> Non-blocking fill those issue slots
CS 540 Spring 2009 GMU
26
ww*2*x *y*z
Schedule 1
$t0,w $t0,$t0,$t0 $t1,x $t0,$t0,$t1 $t1,y $t0,$t0,$t1 $t1,z $t0,$t0,$t1 $t0,w
Schedule 2
$t0,w $t1,x $t2,y $t0,$t0,$t0 $t0,$t0,$t1 $t1,z $t0,$t0,$t2 $t0,$t0,$t1 $t0,w
1 lw 4 add 5 lw 8 mult 9 lw 12 mult 13 lw 16 mult 18 sw done at time 21
1 lw 2 lw 3 lw 4 add 5 mult 6 lw 7 mult 9 mult 11 sw done at time 14
Issue time
CS 540 Spring 2009 GMU
27
Control Hazards
IF ID IF EX MA WB ID EX IF ID EX MA WB
Stall if branch is made
CS 540 Spring 2009 GMU
28
Branch Scheduling
Problem: Branches often take some number of cycles to complete, creating delay slots. Can be a delay between a compare b and its associated branch. Even unconditional branches have delay slots A compiler will try to fill these delay slots with valid instructions (rather than nop).
CS 540 Spring 2009 GMU 29
Example
Assume loads take 2 cycles and branches have a delay slot. 7 cycles instruction lw $t2,$t1(4) lw $t3,$(t1)(8) add $t4, $t2, $t3 add $t5, $t2,1 b L1 nop
CS 540 Spring 2009 GMU
start time 1 2 4 5 6 7
30
Can look at the dependencies between the statements and move a statement into the delay slot. 5 cycles Filling Delay 2 branches 1
4 3
Example
instruction lw $t2,$t1(4) lw $t3,$(t1)(8) add $t5, $t2,1 b L1 add $t4, $t2, $t3
CS 540 Spring 2009 GMU
start time 1 2 3 4 5
31
Filling the delay slot in the SPARC architecture
N
Y
CS 540 Spring 2009 GMU
32
Register Allocation
How to best use the bounded number of registers.
Reducing load/store operations What are best values to keep in registers? When can we free registers?
Complications:
special purpose registers operators requiring multiple registers.
CS 540 Spring 2009 GMU 33
Register Allocation Algorithms
Local (basic block level):
Basic - using liveness information Register Allocation using graph coloring
Global (CFG)
Need to use global liveness information
CS 540 Spring 2009 GMU
34
Basic Code Generation
Deal with each basic block individually. Compute liveness information for the block. Using liveness information, generate code that uses registers as well as possible. At end, generate code that saves any live values left in registers. .
CS 540 Spring 2009 GMU 35
Concept: Variable Liveness
For some statement s, variable x is live if
there is a statement t that uses x there is a path in the CFG from s to t there is no assignment to x on some path from s to t
A variable is live at a given point in the source code if it could be used before it is defined. Liveness tells us whether we care about the value held by a variable.
CS 540 Spring 2009 GMU 36
Example: When is a live?
a := b + c t1 := a * a b := t1 + a c := t1 * b t2 := c + b a := t2 + t2 Assume a,b and c are used after this basic block
CS 540 Spring 2009 GMU 37
a is live
Example: When is b live?
a := b + c t1 := a * a b := t1 + a c := t1 * b t2 := c + b a := t2 + t2 Assume a,b and c are used after this basic block
CS 540 Spring 2009 GMU 38
Computing live status in basic blocks
Input: A basic block. Output: For each statement, set of live variables 1. Initially non-temporary all variables go into live set (L). 2. for i = last statement to first statement:
for statement i: x := y op z 1. Attach L to statement i. 2. Remove x from set L. 3. Add y and z to set L.
CS 540 Spring 2009 GMU 39
Example
live = { live = { t1 := a * a live = { b := t1 + a live = { c := t1 * b live = { t2 := c + b live = { a := t2 + t2 live = {a,b,c}
CS 540 Spring 2009 GMU 40
a := b + c
Example Answers
live = {} a := b + c live = {} t1 := a * a live = {} b := t1 + a live = {} c := t1 * b live = {} t2 := c + b live = {b,c,t2} a := t2 + t2 live = {a,b,c}
CS 540 Spring 2009 GMU 41
Example Answers
live = {} live = {} t1 := a * a live = {} b := t1 + a live = {} c := t1 * b live = {b,c} t2 := c + b live = {b,c,t2} a := t2 + t2 live = {a,b,c}
CS 540 Spring 2009 GMU 42
a := b + c
Example Answers
live = {} live = {} t1 := a * a live = {} b := t1 + a live = { b,t1} c := t1 * b live = {b,c} t2 := c + b live = {b,c,t2} a := t2 + t2 live = {a,b,c}
CS 540 Spring 2009 GMU 43
a := b + c
Example Answers
live = {} live = {} t1 := a * a live = {a,t1} b := t1 + a live = { b,t1} c := t1 * b live = {b,c} t2 := c + b live = {b,c,t2} a := t2 + t2 live = {a,b,c}
CS 540 Spring 2009 GMU 44
a := b + c
Example Answers
live = {} a := b + c live = {a} t1 := a * a live = {a,t1} b := t1 + a live = { b,t1} c := t1 * b live = {b,c} t2 := c + b live = {b,c,t2} a := t2 + t2 live = {a,b,c}
CS 540 Spring 2009 GMU 45
Example Answers
live = {b,c} live = {a} t1 := a * a live = {a,t1} b := t1 + a live = { b,t1} c := t1 * b live = {b,c} t2 := c + b live = {b,c,t2} a := t2 + t2 live = {a,b,c}
CS 540 Spring 2009 GMU
what does this mean???
a := b + c
46
Basic Code Generation
Deal with each basic block individually. Compute liveness information for the block. Using liveness information, generate code that uses registers as well as possible. At end, generate code that saves any live values left in registers. .
CS 540 Spring 2009 GMU 47
Basic Code Generation
Idea: Deal with the instructions from beginning to end. For each instruction,
Use registers whenever possible. A non-live value in a register can be discarded, freeing that register.
Data Structures:
Register Descriptor - register status (empty, full) and contents (one or more "values") Address descriptor - the location (or locations) where the current value for a variable can be found (register, stack, memory)
.
CS 540 Spring 2009 GMU
48
Instruction type: x := y op z
1. Choose Rx, the register where the result (x) will be kept.
If y (or z) is in a register t alone and not live, choose Rx = t 2. Else if there is a free register t, choose Rx = t 3. Else must free up a register for Rx 1.
2. Find Ry. If y is not in a register, generate load into a free register (or Rx) 3. Find Rz. If z is not in a register, generate load into a free register (can use Rx if not used by y). 4. Generate: OP Rx, Ry, Rz
CS 540 Spring 2009 GMU 49
Instruction type: x := y op z
5. Update information about the current best location of x 6. If x is in a register, update that registers information 7. If y and/or z are not live after this instruction, update register and address descriptors according.
CS 540 Spring 2009 GMU 50
Example Code
live = {b,c} a := b + c live = {a} t1 := a * a live = {a,t1} b := t1 + a live = { b,t1} c := t1 * b live = {b,c} t2 := c + b live = {b,c,t2} a := t2 + t2 live = {a,b,c}
CS 540 Spring 2009 GMU 51
Returning to live Example
Initially
Three Registers: ( -, -, -) all empty current values: (a,b,c,t1,t2) = (m,m,m, -, -)
instruction 1: a := b + c, Live = {a }
Ra = $t0, Rb = $t0 , Rc = $t1 lw $t0,b lw $t1,c add $t0,$t0,$t1
Registers: (a, -, -)
Dont need to keep track of b or c since arent live.
current values: ($t0,m,m, -, -)
CS 540 Spring 2009 GMU 52
instruction 2: t1 := a * a, Live = {a,t1}
Rt1 = $t1 (since a is live) mul $t1,$t0,$t0
Registers: (a,t1, -) current values: ($t0,m,m,$t1, -)
instruction 3: b := t1 + a, Live = {b,t1}
Since a is not live after call, Rb = $t0 add $t0,$t1,$t0
Registers: (b,t1, -) current values: (m,$t0,m,$t1, -)
CS 540 Spring 2009 GMU
53
instruction 4: c := t1 * b, Live = {b,c }
Since t1 is not live after call Rc = $t1 mul $t1,$t1,$t0
Registers: (b,c, -) current values: (m,$t0,$t1, -, -)
instruction 5: t2 := c + b, Live = {b,c,t2 }
Rc = $t2 add $t2,$t1,$t0
Registers: (b,c,t2) current values: (m,$t0,$t1, -,$t2)
CS 540 Spring 2009 GMU
54
instruction 6: a := t2 + t2, Live = {a,b,c}
add $t2,$t2,$t2
Registers: (b,c,a) current values: ($t2,$t0,$t1, -,-)
Since end of block, move live variables:
sw $t2,a sw $t0,b sw $t1,c
all registers available all live variables moved to memory
CS 540 Spring 2009 GMU
55
Generated code
lw $t0,b lw $t1,c add $t0,$t0,$t1 mul $t1,$t0,$t0 add $t0,$t1,$t0 mul $t1,$t1,$t0 add $t2,$t1,$t0 add $t2,$t2,$t2 sw $t2, a sw $t0,b sw $t1,c a := b + c
t1 := a * a b := t1 + a c := t1 * b t2 := c + b a := t2 + t2 Cost = 16 How does this compare to nave approach?
56
CS 540 Spring 2009 GMU
Liveness information allows us to keep values in registers if they will be used later (efficiency) Why do we assume all variables are live at the end of blocks? Can we do better? Why do we need to save live variables at the end? We might have to reload them in the next block.
CS 540 Spring 2009 GMU
57
Register Allocation with Graph Coloring
Local register allocation - graph coloring problem. Uses liveness information. Allocate K registers where each register is associated with one of the K colors.
CS 540 Spring 2009 GMU
58
Graph Coloring
The coloring of a graph G = (V,E) is a mapping C: V S, where S is a finite set of colors, such that if edge vw is in E, C(v) <> C(w). Problem is NP (for more than 2 colors) no polynomial time solution. Fortunately there are approximation algorithms.
CS 540 Spring 2009 GMU 59
Coloring a graph with K colors
K=3 K=4
No color for this node
CS 540 Spring 2009 GMU
60
Register Allocation and Graph K-Coloring
K = number of available registers G = (V,E) where Vertex set V = {Vs | s is a program variable} Edge Vs Vt in E if s and t can be live at the same time G is an interference graph
CS 540 Spring 2009 GMU 61
Algorithm: K registers
1. Compute liveness information for the basic block. 2. Create interference graph G - one node for each variable, an edge connecting any two variables alive simultaneously.
CS 540 Spring 2009 GMU
62
Example Interference Graph
a := b + c t1 := a * a b := t1 + a c := t1 * b t2 := c + b a := t2 + t2 {b,c} {a} t1 {t1,a} {b,t1} {b,c} {b,c,t2} {a,b,c}
a c
b
t2
CS 540 Spring 2009 GMU
63
Algorithm: K registers
3. Simplify - For any node m with fewer than K
neighbors, ...