Upload
carol-walton
View
217
Download
0
Embed Size (px)
Citation preview
Compilation: A Retrospective
CS 671April 29, 2008
2 CS 671 – Spring 2008
What You’ve Learned This Semester
What happens when you compile your code
Theory of compilers– Internal challenges and solutions: widely-used algorithms– Available tools and their other applications– Traditional and modern challenges
CompilerHigh-Level
Programming Languages
Machine Code
Error Messages
3 CS 671 – Spring 2008
An Interface to High-Level Languages
Programmers write in high-level languages• Increases productivity• Easier to maintain/debug• More portable
HLLs also protect the programmer from low-level details• Registers and caches – the register keyword• Instruction selection• Instruction-level parallelism
The catch: HLLs are less efficient
CompilerHigh-Level
Programming
Languages
Machine Code
4 CS 671 – Spring 2008
An Interface to Computer Architectures
Parallelism• Instruction level
– multiple operations at once; minimize dependences• Processor level
– multiple threads at once; minimize synchronization
Memory Hierarchies• Register allocation (only portion explicitly managed in SW)• Code and data layout (helps the hardware cache manager)
Designs driven by how well compilers can leverage new features!
CompilerHigh-Level
Programming Languages
Machine Code
5 CS 671 – Spring 2008
Simplified Compiler Structure
Lexical Analysis
Parsing
Intermediate Code Generation
Code Generation
Source code(character stream)if (b==0) a = b;
Assembly code(character stream)CMP CX, 0CMOVZ CX, DX
Token stream
Abstract syntax tree
Intermediate code
Front End
Back EndMachine dependent
Machine independent
Code Optimization
IR
6 CS 671 – Spring 2008
Building a Lexer
Specification
“if”“while”[a-zA-Z][a-zA-Z0-9]*[0-9][0-9]*()
NFA for each RE Giant NFA
Giant DFA Table-driven code
7 CS 671 – Spring 2008
High Level View
Regular expressions = specification
Finite automata = implementation
Every regex has a FSA that recognizes its language
Scanner
ScannerGenerator
source code
specification
tokens
Design time
Compile time
8 CS 671 – Spring 2008
Lex: A Lexical Analyzer Generator
• Lex produces a C program from a lexical specification • http://www.epaperpress.com/lexandyacc/index.html
%%
DIGITS [0-9]+
ALPHA [A-Za-z]
CHARACTER {ALPHA}|_
IDENTIFIER {ALPHA}({CHARACTER}|{DIGITS})*
%%
if {return IF; }
{IDENTIFIER} {return ID; }
{DIGITS} {return NUM; }
([0-9]+”.”[0-9]*)|([0-9]*”.”[0-9]+) {return REAL; }
. {error(); }
9 CS 671 – Spring 2008
Phases of a Compiler
Lexical Analysis
Parsing
Intermediate Code Generation
Code Generation
Source code(character stream)if (b==0) a = b;
Assembly code(character stream)CMP CX, 0CMOVZ CX, DX
Token stream
Abstract syntax tree
Intermediate code
Front End
Back EndMachine dependent
Machine independent
Code Optimization
IR
10 CS 671 – Spring 2008
Parsing – Syntax Analysis
• Convert a linear structure – sequence of tokens – to a hierarchical tree-like structure – an AST
• The parser imposes the syntax rules of the language
• Work should be linear in the size of the input type consistency cannot be checked in this phase
•Deterministic context free languages for the basis
• Bison and yacc allow a user to construct parsers from CFG specifications
11 CS 671 – Spring 2008
Context-Free Grammar Terminology
• Terminals– Token or ε
• Non-terminals– Syntactic variables
• Start symbol– A special nonterminal is designated (S)
• Productions– Specify how non-terminals may be expanded to
form strings– LHS: single non-terminal, RHS: string of terminals
or non-terminals
• Vertical bar is shorthand for multiple productions
S (S) S
S ε
12 CS 671 – Spring 2008
Shift-Reduce Parsing
Bottom-up parsing uses two kinds of actions: Shift and Reduce
Shift: Move I one place to the right• Shifts a terminal to the left string
E + (I int ) E + (int I )
Reduce: Apply an inverse production at the right end of the left string• If E E + ( E ) is a production, then
E + (E + ( E ) I ) E +(E I )
13 CS 671 – Spring 2008
Shift-Reduce Parsing Table
Action table
1. shift and goto state n
2. reduce using X → γ– pop symbols γ off stack– using state label of top (end) of stack, look up X in
goto table and goto that state
• DFA + stack = push-down automaton (PDA)
next actions
next state on
reduction
state
terminal symbols non-terminal symbols
14 CS 671 – Spring 2008
Parsing Table
( ) id , $ S L
1 s3 s2 g4
2 S→id S→id S→id S→id S→id
3 s3 s2 g7 g5
4 accept
5 s6 s8
6 S→(L)
S→(L)
S→(L)
S→(L)
S→(L)
7 L→S L→S L→S L→S L→S
8 s3 s2 g9
9 L→L,S
L→L,S
L→L,S
L→L,S
L→L,S
15 CS 671 – Spring 2008
Yacc / Bison
•Yet Another Compiler Compiler
•Automatically constructs an LALR(1) parsing table from a set of grammar rules
•Yacc/Bison specification:
parser declarations%%grammar rules%%auxiliary code
bison –vd file.y
-or-
yacc –vd file.y
y.tab.cy.tab.hy.output
file.y
16 CS 671 – Spring 2008
Parsing - Semantic Analysis
• Calculates the program’s “meaning”
• Rules of the language are checked (variable declaration, type checking)
• Type checking also needed for code generation (code gen for a + b depends on the type of a and b)
17 CS 671 – Spring 2008
Symbol Table Implementation
Can consist of:
• a hash table for all names, and
•a stack to keep track of scope
y \
x \
x
y
x
y
x
aa \
x
X
Scope change
18 CS 671 – Spring 2008
Typical Semantic Errors
Traverse the AST created by the parser to find:
•Multiple declarations: a variable should be declared (in the same scope) at most once
•Undeclared variable: a variable should not be used before being declared
•Type mismatch: type of the left-hand side of an assignment should match the type of the right-hand side
•Wrong arguments: methods should be called with the right number and types of arguments
19 CS 671 – Spring 2008
Stack Frames
Activation record or stack frame stores:
• local vars
• parameters
• return address
• temporaries
• (…etc)
(Frame size not known until
late in the compilation process)
Arg n…
Arg 2Arg 1
Static linkLocal vars
Ret addressTemporariesSaved regs
Arg m…
Arg 1Static link
current frame
previous frame
next frame
sp
fp
20 CS 671 – Spring 2008
Phases of a Compiler
Lexical Analysis
Parsing
Intermediate Code Generation
Code Generation
Source code(character stream)if (b==0) a = b;
Assembly code(character stream)CMP CX, 0CMOVZ CX, DX
Token stream
Abstract syntax tree
Intermediate code
Front End
Back EndMachine dependent
Machine independent
Code Optimization
IR
21 CS 671 – Spring 2008
Intermediate Code Generation
• Makes it easy to port compiler to other architectures– e.g., Pentium to MIPS
• Can also be the basis for interpreters – such as in Java
• Enables optimizations that are not machine specific
AST IR PowerPC
Alpha
x86optimize
22 CS 671 – Spring 2008
Phases of a Compiler
Lexical analyzer
Syntax analyzer
Semantic analyzer
Intermediate code generator
Code optimizer
Code generator
Source program
Target program
Intermediate Code Optimization
• Constant propagation, dead code elimination, common sub-expression elimination, strength reduction, etc.
• Based on dataflow analysis – properties that are independent of execution paths
23 CS 671 – Spring 2008
Analysis and Transformation
Most optimizations require some global understanding of program flow• Moving, removing, rearranging instructions
Achieve understanding by discovering the control flow of the procedure• What blocks follow/are reachable from other blocks• Where loops exist (focus optimization efforts)• We call this Control-Flow Analysis
Connect definitions and uses of variables• We call this Data-Flow Analysis
24 CS 671 – Spring 2008
Data-Flow Analysis
Properties:• either a forward analysis (out as function of in) or • a backward analysis (in as a function of out).
• either an “along some path” problem or• an “along all paths” problem.
out[I] = ( in[I] – kill[I] ) gen[I]
in[B] = out[B’]B’ succ(B)
25 CS 671 – Spring 2008
Static Single Assignment Form
if (…)
X 5 X 3
Y X
B1
B2 B3
B4
if (…)
X0 5 X1 3
X2 (X0, X1)Y0 X2
B1
B4
B2 B3
Before SSA After SSA
26 CS 671 – Spring 2008
Optimizations
What are they?• Code transformations• Improve some metric
Metrics• Performance: time, instructions, cycles• Space: Reduce memory usage• Code Size• Energy
27 CS 671 – Spring 2008
Optimizations
InliningConstant foldingAlgebraic simplificationConstant propagationDead code eliminationLoop-invariant code motionCommon sub-expression eliminationStrength reductionBranch prediction/optimizationRegister allocationLoop unrollingCache optimization
High-level IR
Low-level IR
28 CS 671 – Spring 2008
Scope of Optimization
Local (or single block)• Confined to straight-line code• Simplest to analyze
Intraprocedural (or global)• Consider the whole procedure
Interprocedural (or whole program)• Consider the whole program
29 CS 671 – Spring 2008
Phases of a Compiler
Lexical analyzer
Syntax analyzer
Semantic analyzer
Intermediate code generator
Code optimizer
Code generator
Source program
Target program
Native Code Generation
• Intermediate code is translated into native code
• Register allocation, instruction selection
Native Code Optimization
• Peephole optimizations – small window is optimized at a time
30 CS 671 – Spring 2008
mov t1, [bp+x]mov t2, t1add t2, 1mov [bp+x], t2
Instruction Tiling
x = x + 1;
MOVE
MEM
FP
+
x
+
MEM
FP
+
x
1
t2
t1
31 CS 671 – Spring 2008
Register Allocation
s1 2s2 4s3 s1 + s2s4 s1 + 1s5 s1 * s2s6 s4 * 2
s1 s2 s3 s4 s5 s6
Live Range Interference
S1 S4
S3 S2
S5
S6
S1 S4
S3 S2
S5
S6
Graph Coloring r1 2r2 4r3 r1 + r2r3 r1 + 1r1 r1 * r2r2 r3 * 2
Result
r1 greenr2 bluer3 pink
32 CS 671 – Spring 2008
Instruction Scheduling
•Create a DAG of dependences
•Determine priority
•Schedule instructions with– Ready operands– Highest priority
•Heuristics: If multiple possibilities, fall back on other priority functions
– Height, slack, register usage, etc.
1m 2m
4m
7
3
65
8
10
9m
33 CS 671 – Spring 2008
Modern Topics!
• Alternatives to the static compilation model
• Compiling for the Core2
• Compiling for GPUs
• Compiling for power and temperature
• Compiling for parallelism
34 CS 671 – Spring 2008
Alternatives to the Traditional Model
Static Compilation
All work is done “ahead-of-time”
Just-in-Time Compilation
Postpone some compilation tasks
Multiversioning and Dynamic Feedback
Include multiple options in binary
Dynamic Binary Optimization
Traditional compilation model
Executables can adapt
35 CS 671 – Spring 2008
Just-in-Time Compilation
High-Level Programming Languages
Machine Code
FrontEnd
BackEnd
Error Messages
Ship bytecodes (think IR) rather than binaries• Binaries execute on machines• Bytecodes execute on virtual machines
Compiler
36 CS 671 – Spring 2008
Compiling for the Core Architecture
Netburst architecture: has trace cache with decoded instructions
Core architecture: instructions are repeatedly fetched and decoded
Problems:
• Code alignment! (Fetch, brpred effects)
4008c0 44 8b
4008d0 04 8d A0 64 56 00 8b 34 8d 20 4a 50 00 44 01 C6
4008e0 42 8d 3c 06 41 83 C0 F6 01 F2 89 34 8d 40 7f 5c
4008f0 00 89 3c 8d 20 4a 50 00 44 89 04 8d A0 64 56 00
400900 41 29 F8 44 29 C2 48 83 c1 01 48 81 F9 A0 86 01
400910 00 7c Bb
20% Speedup!!!
37 CS 671 – Spring 2008
Compiling for GPUs
CPUs•Lots of instructions little data
– Out of order exec – Branch prediction
•Reuse and locality•Task parallel•Needs OS•Complex sync•Latency machines
GPUs•Few instructions lots of data
– SIMD– Hardware threading
•Little reuse•Data parallel•No OS•Simple sync•Throughput machines
38 CS 671 – Spring 2008
Bug ReportBug Report
Graphics Shadow acne
CompilerRound off error
39 CS 671 – Spring 2008
40 CS 671 – Spring 2008
Shader Compiler (SC)
Developers ship games in byte code– Each time a game starts the shader is compiled
Compiler is hidden in driver – No user gets to set options or flags
Compiler updates with new driver (once a month)
Compile done each time game is run
About ½ code is traditional compiler, all the usual stuff• Strange features: SC fights MS compiler
41 CS 671 – Spring 2008
Power-Aware Computing
42 CS 671 – Spring 2008
Temperature
Capacitive (Dynamic) Power Static (Leakage) Power
Minimum Voltage
20 cycles
Di/Dt (Vdd/Gnd Bounce)
Vol
tage
(V
)C
urr
ent
(A)
VOUT
CL ISub
VIN
IGate
Vin Vout
CL
Vdd
Power Issues in Microprocessors
43 CS 671 – Spring 2008
Code Optimizations for Low Power
Reorder instructions to reduce switching effect at functional units and I/O buses
Operand swapping• Swap the operands at the input of multiplier• Result is unaltered, but power changes significantly!
Other standard compiler optimizations• Software pipelining, dead code elimination,
redundancy elimination
Use processor-specific instruction styles• on ARM the default int type is ~ 20% more efficient
than char or short (sign/zero extension)
44 CS 671 – Spring 2008
Code Optimization of Parallel Programs
• Crises lead to paradigm shifts
• Most of our algorithms break down in light of parallelism!
• Many “band aids” exist, need a unified solution
• Need a way to represent synchronization, parallelism in our dataflow analyses
• Need a new IR … PIR– CFG + PDG = PPG
• Can then update our dataflow analyses
45 CS 671 – Spring 2008
The Big Picture
We now know:– All of the components of a compiler– What needs to be done statically vs. dynamically– The potential impact of language or architecture
changes– Why Java moved the “back-end” to run time– What compiler researchers are working on in
2008!