Compiler Construction Compiler Construction Semantic Analysis I.
Compiler Optimizationviren/Courses/2014/compiler/Lecture2.pdf · General Structure of a Modern...
Transcript of Compiler Optimizationviren/Courses/2014/compiler/Lecture2.pdf · General Structure of a Modern...
CADSL
Compiler Optimization Intermediate Representation
Virendra Singh
Associate Professor Computer Architecture and Dependable Systems Lab
Department of Electrical Engineering Indian Institute of Technology Bombay
http://www.ee.iitb.ac.in/~viren/ E-mail: [email protected]
A Short Course on Compiler Construction & Optimization Lecture 2 (23 May 2014)
CADSL
From Source to Executable
Compiler main() sub1() data
source program foo.c
main sub1 data
object modules foo.o
prin9 scanf gets fopen exit data ...
sta;c library libc.a
Linkage Editor
main sub1 data prin9 exit data
load module a.out
other
programs ...
main sub1 data prin9 exit data
other ... ...
kernel
Machine memory
?
(system calls)
Loader
(Run Time)
Dynamic library case not shown
“Load ;me”
23 May 2014 Compilers@EE-IITB 2
CADSL
General Structure of a Modern Compiler
Lexical Analysis
Syntax Analysis
Semantic Analysis
Controlflow/Dataflow
Optimization
Code Generation
Source Program
Assembly Code
Scanner
Parser
High-level IR to low-level IR conversion
Build high-level IR Context
Symbol Table
CFG
Machine independent asm to machine dependent
Front end
Back end
23 May 2014 Compilers@EE-IITB 3
CADSL
Intermediate Representation (aka IR)
• The compilers internal representa1on – Is language-‐independent and machine-‐independent
AST IR
Pentium
Java bytecode
Itanium
TI C5x
ARM
optimize
Enables machine independent and machine dependent optis
23 May 2014 Compilers@EE-IITB 4
CADSL
What Makes a Good IR? • Captures high-‐level language constructs
– Easy to translate from AST – Supports high-‐level op1miza1ons
• Captures low-‐level machine features – Easy to translate to assembly – Supports machine-‐dependent op1miza1ons
• Narrow interface: small number of node types (instruc1ons) – Easy to op1mize – Easy to retarget
23 May 2014 Compilers@EE-IITB 5
CADSL
Kinds of IR • Abstract syntax trees (AST) • Linear operator form of tree (e.g., posJix nota1on)
• Directed acyclic graphs (DAG) • Control flow graphs (CFG) • Program dependence graphs (PDG) • Sta1c single assignment form (SSA) • 3-‐address code • Hybrid combina1ons
23 May 2014 Compilers@EE-IITB 6
CADSL
Categories of IR • Structural
– graphically oriented (trees, DAGs) – nodes and edges tend to be large – heavily used on source-‐to-‐source translators
• Linear – pseudo-‐code for abstract machine – large varia1on in level of abstrac1on – simple, compact data structures – easier to rearrange
• Hybrid – combina1on of graphs and linear code (e.g. CFGs) – aRempt to achieve best of both worlds
23 May 2014 Compilers@EE-IITB 7
CADSL
Important IR properties • Ease of genera1on • Ease of manipula1on • Cost of manipula1on • Level of abstrac1on • Freedom of expression (!) • Size of typical procedure • Original or deriva1ve
23 May 2014 Compilers@EE-IITB 8
Subtle design decisions in the IR can have far-reaching effects on the speed and effectiveness of the compiler! è Degree of exposed detail can be crucial
CADSL
Abstract Syntax Tree
23 May 2014 Compilers@EE-IITB 9
An AST is a parse tree
A linear operator form of this tree (postfix) would be:
x 2 y * -!
CADSL
Directed Acyclic Graph
23 May 2014 Compilers@EE-IITB 10
A DAG is an AST with unique, shared nodes for each value.
x := 2 * y + sin(2*x)!z := x / 2!
CADSL
Control Flow Graph • A CFG models transfer of control in a program
– nodes are basic blocks (straight-‐line blocks of code) – edges represent control flow (loops, if/else, goto …)
23 May 2014 Compilers@EE-IITB 11
if x = y then!!S1!else!!S2!end!S3!
CADSL
3-address code
23 May 2014 Compilers@EE-IITB 12
• Statements take the form: x = y op z!– single operator and at most three names
x – 2 * y! t1 = 2 * y!t2 = x – t1!
Advantages: — Compact form — Names for intermediate values
CADSL
Typical 3-address codes
assignments!
x = y op z!
x = op y!
x = y[i]!
x = y!
branches! goto L!
conditional branches! if x relop y goto L!
procedure calls!param x!param y!call p!
address and pointer assignments!
x = &y!*y = z!
23 May 2014 Compilers@EE-IITB 13
CADSL
IR choices • Other hybrids exist
– combina1ons of graphs and linear codes – CFG with 3-‐address code for basic blocks
• Many variants used in prac1ce – no widespread agreement – compilers may need several different IRs!
• Advice: – choose IR with right level of detail – keep manipula1on costs in mind
23 May 2014 Compilers@EE-IITB 14
CADSL
Static Single Assignment Form • Goal: simplify procedure-‐global op1miza1ons
• Defini3on:
15
Program is in SSA form if every variable is only assigned once
23 May 2014 Compilers@EE-IITB 15
CADSL
Static Single Assignment (SSA) • Each assignment to a temporary is given a unique name – All uses reached by that assignment are renamed – Compact representa1on – Useful for many kinds of compiler op1miza1on …
23 May 2014 Compilers@EE-IITB 16
Ron Cytron, et al., “Efficiently compu3ng sta3c single assignment form and the control dependence graph,” ACM TOPLAS., 1991.
x := 3;!x := x + 1;!x := 7;!x := x*2;!
x1 := 3;!x2 := x1 + 1;!x3 := 7;!x4 := x3*2;!
è
CADSL
Why Static? • Why Sta1c?
– We only look at the sta3c program – One assignment per variable in the program
• At run1me variables are assigned mul1ple 1mes!
23 May 2014 Compilers@EE-IITB 17
CADSL
Example: Sequence
a := b + c!b := c + 1!d := b + c!a := a + 1!e := a + b!
a1 := b1 + c1!b2 := c1 + 1!d1 := b2 + c1!a2 := a1 + 1!e1 := a2 + b2!
Original SSA
Easy to do for sequential programs:
23 May 2014 Compilers@EE-IITB 18
CADSL
Example: Condition
if B then!!a := b!else!!a := c!end!!… a …!
if B then!!a1 := b!else!!a2 := c!End!!!… a? …!
Original SSA
Conditions: what to do on control-flow merge?
23 May 2014 Compilers@EE-IITB 19
CADSL
Solution: Φ-Function
if B then!!a := b!else!!a := c!end!!… a …!
if B then!!a1 := b!else!!a2 := c!End!a3 := Φ(a1,a2)!!… a3 …!
Original SSA
Conditions: what to do on control-flow merge?
23 May 2014 Compilers@EE-IITB 20
CADSL
The Φ-Function • Φ-‐func1ons are always at the beginning of a basic block
• Select between values depending on control-‐flow
• ak+1 := Φ (a1…ak): the block has k preceding blocks PHI-‐func3ons are evaluated simultaneously within a basic block.
23 May 2014 Compilers@EE-IITB 21
CADSL
SSA and CFG • SSA is normally used for control-‐flow graphs (CFG)
• Basic blocks are in 3-‐address form
23 May 2014 Compilers@EE-IITB 22
CADSL
Recall: Control flow graph • A CFG models transfer of control in a program
– nodes are basic blocks (straight-‐line blocks of code) – edges represent control flow (loops, if/else, goto …)
if x = y then!!S1!
else!!S2!
end!S3!
23 May 2014 Compilers@EE-IITB 23
CADSL
SSA: a Simple Example
if B then!!a1 := 1!
else!!a2 := 2!
End!a3 := PHI(a1,a2)!!… a3 …!
23 May 2014 Compilers@EE-IITB 24
CADSL
Recall: IR
• front end produces IR • optimizer transforms IR to more efficient program • back end transform IR to target code
23 May 2014 Compilers@EE-IITB 25
CADSL
SSA as IR
23 May 2014 Compilers@EE-IITB 26
CADSL
Transforming to SSA • Problem: Performance / Memory
– Minimize number of inserted Φ-‐func1ons – Do not spend too much 1me
• Many rela1vely complex algorithms
27 23 May 2014 Compilers@EE-IITB 27
CADSL
Minimal SSA • Two steps:
– Place Φ-‐func1ons – Rename Variables
• Where to place Φ-‐func1ons?
• We want minimal amount of needed Φ – Save memory – Algorithms will work faster
28 23 May 2014 Compilers@EE-IITB 28
CADSL
Optimization: The Idea
• Transform the program to improve efficiency
• Performance: faster execu1on • Size: smaller executable, smaller memory footprint
Tradeoffs: 1) Performance vs. Size 2) Compila;on speed and memory
29 23 May 2014 Compilers@EE-IITB
CADSL
Optimization on many levels
• Op1miza1ons both in the op1mizer and back-‐end
30 23 May 2014 Compilers@EE-IITB
CADSL
Examples for Optimizations • Constant Folding / Propaga1on • Copy Propaga1on • Algebraic Simplifica1ons • Strength Reduc1on • Dead Code Elimina1on
– Structure Simplifica1ons
• Loop Op1miza1ons • Par1al Redundancy Elimina1on • Code Inlining
31 23 May 2014 Compilers@EE-IITB
CADSL
Constant Folding • Evaluate constant expressions at compile 1me • Only possible when side-‐effect freeness guaranteed
c:= 1 + 3 c:= 4
true not false
Caveat: Floats — implementation could be different between machines!
32 23 May 2014 Compilers@EE-IITB
CADSL
Constant Propagation
• Variables that have constant value, e.g. b := 3 – Later uses of b can be replaced by the constant – If no change of b between!
b := 3!c := 1 + b!d := b + c!
b := 3!c := 1 + 3!d := 3 + c!
Analysis needed, as b can be assigned more than once!
33 23 May 2014 Compilers@EE-IITB
CADSL © Marcus Denker
Copy Propagation
• for a statement x := y • replace later uses of x with y, if x and y have not been changed.
x := y!c := 1 + x!d := x + c!
x := y!c := 1 + y!d := y + c!
Analysis needed, as y and x can be assigned more than once!
34 23 May 2014 Compilers@EE-IITB
CADSL © Marcus Denker
Algebraic Simplifications
• Use algebraic proper1es to simplify expressions
-(-i)! i!
b or: true! true!
Important to simplify code for later optimizations
35 23 May 2014 Compilers@EE-IITB
CADSL
Strength Reduction
• Replace expensive opera1ons with simpler ones
• Example: Mul1plica1ons replaced by addi1ons
y := x * 2! y := x + x!
Peephole optimizations are often strength reductions
36 23 May 2014 Compilers@EE-IITB
CADSL
Dead Code • Remove unnecessary code
– e.g. variables assigned but never read
b := 3!c := 1 + 3!d := 3 + c!
c := 1 + 3!d := 3 + c!
> Remove code never reached
if (false) {a := 5}!
if (false) {}!
37 23 May 2014 Compilers@EE-IITB
CADSL
Simplify Structure
• Similar to dead code: Simplify CFG Structure
• Op1miza1ons will degenerate CFG
• Needs to be cleaned to simplify further op1miza1on!
38 23 May 2014 Compilers@EE-IITB
CADSL
Delete Empty Basic Blocks
39 23 May 2014 Compilers@EE-IITB
CADSL
Fuse Basic Blocks
40 23 May 2014 Compilers@EE-IITB
CADSL
Common Subexpression Elimination (CSE)
Common Subexpression: • There is another occurrence of the expression whose evalua1on always precedes this one
• operands remain unchanged
Local (inside one basic block): When building IR Global (complete flow-‐graph)
41 23 May 2014 Compilers@EE-IITB
CADSL
Example CSE
b := a + 2!c := 4 * b! b < c?!
b := 1!
d := a + 2!
t1 := a + 2!b := t1!c := 4 * b! b < c?!
b := 1!
d := t1!
42 23 May 2014 Compilers@EE-IITB
CADSL
Loop Optimizations • Op1mizing code in loops is important
– ojen executed, large payoff
• All op1miza1ons help when applied to loop-‐bodies
• Some op1miza1ons are loop specific
43 23 May 2014 Compilers@EE-IITB
CADSL
Loop Invariant Code Motion • Move expressions that are constant over all itera1ons out of the loop
44 23 May 2014 Compilers@EE-IITB
CADSL
Induction Variable Optimizations
• Values of variables form an arithme1c progression
integer a(100)!do i = 1, 100! a(i) = 202 - 2 * i!endo!
integer a(100)!t1 := 202!do i = 1, 100! t1 := t1 - 2! a(i) = t1!endo!
value assigned to a decreases by 2
uses Strength Reduction
45 23 May 2014 Compilers@EE-IITB
CADSL
Partial Redundancy Elimination (PRE)
• Combines mul1ple op1miza1ons: – global common-‐subexpression elimina1on – loop-‐invariant code mo1on
• Par;al Redundancy: computa1on done more than once on some path in the flow-‐graph
• PRE: insert and delete code to minimize redundancy.
46 23 May 2014 Compilers@EE-IITB
CADSL
Code Inlining • All op1miza1ons up to now were local to one procedure
• Problem: procedures or func1ons are very short – Especially in good OO code!
• Solu1on: Copy code of small procedures into the caller – OO: Polymorphic calls. Which method is called?
47 23 May 2014 Compilers@EE-IITB
CADSL
Example: Inlining
a := power2(b)! power2(x) {! return x*x!}!
a := b * b!
48 23 May 2014 Compilers@EE-IITB
CADSL
Optimizations in the Backend
• Register Alloca1on • Instruc1on Selec1on • Peep-‐hole Op1miza1on
49 23 May 2014 Compilers@EE-IITB
CADSL
Register Allocation • Processor has only finite amount of registers
– Can be very small (x86)
• Temporary variables – non-‐overlapping temporaries can share one register
• Passing arguments via registers • Op1mizing register alloca1on very important for good performance – Especially on x86
50 23 May 2014 Compilers@EE-IITB
CADSL © Marcus Denker
Instruction Selection
• For every expression, there are many ways to realize them for a processor
• Example: Mul1plica1on*2 can be done by bit-‐shij
Instruc3on selec3on is a form of op3miza3on
51 23 May 2014 Compilers@EE-IITB
CADSL
Peephole Optimization
• Simple local op1miza1on • Look at code “through a hole”
– replace sequences by known shorter ones – table pre-‐computed
store R,a; !load a,R!
store R,a; !
imul 2,R; ashl 1,R;
Important when using simple instruc3on selec3on!
52 23 May 2014 Compilers@EE-IITB
CADSL
Thank You
23 May 2014 Compilers@EE-IITB 53