CSE 501: Compiler Construction Course outline Main focus: program analysis and transformation Models of compilation • how to represent programs? • how to analyze programs? what to analyze? Standard transformations • how to transform programs? what transformations to apply? Basic representations and analyses Study imperative, functional, and object-oriented languages Fancier representations and analyses Prerequisites: Interprocedural representations, analyses, and transformations • CSE 401 or equivalent • for imperative, functional, and OO languages • CSE 505 or equivalent Representations, analyses, and transformations Reading: for parallel machines Appel’s “Modern Compiler Implementation” + ~20 papers from literature Compiler back-end issues • “Compilers: Principles, Techniques, & Tools”, • register allocation a.k.a. the Dragon Book, as a reference • instruction scheduling Coursework: Run-time system issues • periodic homework assignments • garbage collection • major course project • compiling dynamic dispatch, first-class functions, ... • midterm + final Craig Chambers 1 CSE 501 Craig Chambers 2 CSE 501 Why study compilers? Goals for language implementation Meeting area of programming languages, architecture Correctness • capabilities of compilers greatly influences design of these others Efficiency • of: time, data space, code space Program representation and analysis is widely useful • at: compile-time, run-time • software engineering tools • DB query optimizers Support expressive language features • programmable graphics renderers • first-class, higher-order functions • safety checking of code, • dynamic dispatching e.g. in programmable/extensible systems, networks, • exceptions, continuations databases • reflection, dynamic code loading • ... Cool theoretical aspects, too • lattice domains, graph algorithms, computability/complexity Support desirable programming environment features • fast turnaround Opportunity for AI? • separate compilation, shared libraries • source-level debugging • profiling • garbage collection • ... Craig Chambers 3 CSE 501 Craig Chambers 4 CSE 501
Standard compiler organization Compiling to a portable intermediate language Analysis Synthesis of input program of output program Define “portable” intermediate language ( front-end ) ( back-end ) (e.g. Java bytecode, MSIL, SUIF, WIL, C, ...) character Compile multiple languages into it stream intermediate • each such compiler may not be much more than a front-end form Lexical Analysis token Compile to multiple targets from it Optimization stream • may not be much more than back-end Syntactic Analysis intermediate form Maybe interpret/execute directly abstract syntax tree Interpreter Code Generation Semantic Analysis target Advantages: language • reuse of front-ends and back-ends annotated AST • portable “compiled” code Interpreter Intermediate Design of portable intermediate language is hard Code Generation • how universal? intermediate across input language models? target machine models? form • fast interpretation and simple compilation at odds Craig Chambers 5 CSE 501 Craig Chambers 6 CSE 501 Key questions Overview of optimizations How are programs represented in the compiler? First analyze program to learn things about it Then transform the program based on info How are analyses organized/structured? Repeat... Over what region of the program are analyses performed? What analysis algorithms are used? Requirement: don’t change the semantics! • transform input program into semantically equivalent but better output program What kinds of optimizations can be performed? Which are profitable in practice? How should analyses/optimizations be sequenced/combined? Analysis determines when transformations are: • legal How best to compile in face of: • profitable • pointers, arrays • first-class functions • inheritance & message passing • parallel target machines Caveat: “optimize” a misnomer • almost never optimal Other issues: • sometimes slow down some programs on some inputs • speeding compilation (although hope to speed up most programs on most • making compilers portable, table-driven inputs) • supporting tools like debuggers, profilers, garbage collect’rs Craig Chambers 7 CSE 501 Craig Chambers 8 CSE 501
Semantics Scope of analysis Exactly what are the semantics that are to be preserved? Peephole : across a small number of “adjacent” instructions [adjacent in space or time] Subtleties: • trivial analysis • evaluation order • arithmetic properties like associativity, commutativity Local : within a basic block • behavior in “error” cases • simple analysis Intraprocedural (a.k.a. global ): Some languages very precise across basic blocks, within a procedure • programmers always know what they’re getting • analysis more complex: branches, merges, loops Others weaker • allow better performance (but how much?) Interprocedural : across procedures, within a whole program • analysis even more complex: Semantics selected by compiler option? calls, returns • sometimes useful • more useful for higher-level languages • hard with separate compilation Whole-program : analysis examines whole program in order to prove safety Craig Chambers 9 CSE 501 Craig Chambers 10 CSE 501 Catalog of optimizations/transformations common subexpression elimination (CSE) ⇒ x := a + b x := a + b ... ... arithmetic simplifications: y := a + b y := x • constant folding • can also eliminate redundant memory references, ⇒ x := 3 + 4 x := 7 branch tests • strength reduction ⇒ x := y * 4 x := y << 2 partial redundancy elimination (PRE) constant propagation • like CSE, but with earlier expression only available along ⇒ ⇒ x := 5 x := 5 x := 5 subset of possible paths y := x + 2 y := 5 + 2 y := 7 if ... then ⇒ if ... then ... ... copy propagation x := a + b t := a + b; x := t ⇒ x := y x := y end else t := a + b end w := w + x w := w + y ... ... y := a + b y := x pointer/alias analysis ⇒ ⇒ p := &x p := &x p := &x *p := 5 *p := 5 *p := 5 y := x + 1 y := 5 + 1 y := 6 Craig Chambers 11 CSE 501 Craig Chambers 12 CSE 501
dead (unused) assignment elimination Loop optimizations x := y ** z ... // no use of x loop-invariant code motion x := 6 ⇒ for j := 1 to 10 for j := 1 to 10 for i := 1 to 10 t := b[j] partial dead assignment elimination a[i] := a[i] + b[j] for i := 1 to 10 • like DAE, except assignment only used on some later paths a[i] := a[i] + t dead (unreachable) code elimination induction variable elimination ⇒ if false goto _else for i := 1 to 10 for p := &a[1] to &a[10] ... a[i] := a[i] + 1 *p := *p + 1 goto _done • a[i] is several instructions, *p is one _else: ... _done: loop unrolling ⇒ for i := 1 to N for i := 1 to N by 4 a[i] := a[i] + 1 a[i] := a[i] + 1 integer range analysis a[i+1] := a[i+1] + 1 • fold comparisons based on range analysis a[i+2] := a[i+2] + 1 • eliminate unreachable code a[i+3] := a[i+3] + 1 for(index = 0; index < 10; index ++) { if index >= 10 goto _error a[index] := 0 } Craig Chambers 13 CSE 501 Craig Chambers 14 CSE 501 parallelization Call optimizations ⇒ for i := 1 to 1000 forall i := 1 to 1000 a[i] := a[i] + 1 a[i] := a[i] + 1 inlining loop interchange, skewing, reversal, ... ⇒ ⇒ l := ... l := ... l := ... w := 4 w := 4 w := 4 blocking/tiling a := area(l,w) a := l * w a := l << 2 • restructuring loops for better data cache locality • lots of “silly” optimizations become important after inlining interprocedural constant propagation, alias analysis, etc. static binding of dynamic calls • in imperative languages, for call of a function pointer: if can compute unique target of pointer, can replace with direct call • in functional languages, for call of a computed function: if can compute unique value of function expression, can replace with direct call • in OO languages, for dynamically dispatched message: if can deduce class of receiver, can replace with direct call • other possible optimizations even if several possible targets procedure specialization • more generally, partial evaluation Craig Chambers 15 CSE 501 Craig Chambers 16 CSE 501
Recommend
More recommend
