Compiler Optimization: A University Course on Translating and Optimizing User Programs, Slides of Computer Science

Download Compiler Optimization: A University Course on Translating and Optimizing User Programs and more Slides Computer Science in PDF only on Docsity!

Compiler Optimisation^ Michael O’[email protected]

Room 1.06January, 2013

M. O’Boyle^

Compiler Optimisation

3

Course Structure

-^ L1 Introduction and Recap •^ L2 Course Work - again updated from last year •^ 4-5 lectures on classical optimisation (Based on Engineering a Compiler) •^ 5-6 lectures on high level/parallel (Based on Kennedy’s book + papers) •^ 4-5 lectures on adaptive compilation (Based on papers) •^ Additional lectures on course work/ revision/ external talks/ research directions M. O’Boyle^

Compiler Optimisation

5

Compilation

-^ Compilers : map user programs to hardware. Translation - must be correct •^ Hide underlying complexity. Machines are not Von Neumann •^ Current focus : Optimisation go faster, smaller, cooler. •^ 40+ years. In general undecidable, sub-problems at least NP-complete •^ Try to solve undecidable problem in less time than execution! •^ Tackling a universal systems problem: Java to x86, VHDL to netlists etc. •^ Gap between potential performance and actual widening - compilers help? M. O’Boyle^

Compiler Optimisation

6

Compilation as translation vs optimisation

-^ Modern focus is on exploiting architecture features •^ Exploiting parallelism: instruction, thread, multi-core, accelerators •^ Effective management of memory hierarchy registers,LI,L2,L3,Mem,Disk •^ Small architectural changes have big impact •^ Compilers have to be architecture aware -codesign e.g. RISC •^ Optimisation at many levels source, internal formats, assembler M. O’Boyle^

Compiler Optimisation

8

Phase Order

-^ Lexical Analysis:

Finds and verifies basic syntactic items - lexemes, tokens using finite state automata • Syntax Analysis:

Checks tokens follow a grammar based on a context free grammar and builds an Abstract Syntax Tree (AST) • Semantic Analysis:

Checks all names are consistently used.

Various type

checking schemes employed.

Attribute grammar to Milner type inference. Builds a symbol table • Optimisation + Code generation - later lectures M. O’Boyle^

Compiler Optimisation

9

Lexical Analysis Tokens include keywords

int, identifiers

main^ update

and constants

10E

Tokens defined using regular expression (RE), alphabet

Σ,^ |,^ ∗, ǫ

Input to scanner generators translated to NFA and simplified to DFANumber of states = size of table. No impact on scan time complexityModern languages use white space as separators. DO i = 1. 16!

ℓ^ = (a|b|...

|z|A|B...|Z

d^ = (0|^1 |..|

integer =^ dd

real =^ dd^ ∗

.dd∗ exp =^ dd^ ∗

.dd∗Edd∗

M. O’Boyle^

Compiler Optimisation

11

Syntax Analysis Tokens form the words or terminals for the grammar.RE not powerful enough. Use context free grammar (CFG) based on BNF variantsNext strip out syntax sugar and builds ASTForm of CFG determines type of language and parser family.Top down vs Bottom up. Automation, error handling. Grammar rewriting

expr = term (op expr)term = number

|^ id op =^ ∗|^ +^ |−

Example: parse

x^ −^2 ∗^ y M. O’Boyle^

Compiler Optimisation

12

Syntax Analysis

x^ −^2 ∗^ y expr op term id^

−^ term

expr exprop term*^ id y number^2 x Impact on binding of operators.

x^ −^2 ∗^ y^

is parsed as

x^ −^ (2^ ∗^ y

What about

x^ ∗^2 −^ y? M. O’Boyle^

Compiler Optimisation

14

Semantic Analysis

-^ One name can be used for different vars depending on scope. Symbol table •^ Type checking. Attribute grammars augment BNF rules with type rulesexpr = term (op expr)

expr.type = term.type (

Fexpr.type)op^

term = num

|^ id^

term.type = num.type

|^ id.type

op =^ ∗|^ +^ |−

F=^ F|Fop^ ∗

|F+−

x^ −^2 ∗^ y^ int:x, real:y, int

<real

Difficult to add non-local knowledge : Ad-hoc syntax approaches, yaccHigher order functional languages and dynamic typing make things interesting M. O’Boyle^

Compiler Optimisation

15

Semantic Analysis

x^ −^2 ∗^ y^

int:x, real:y, int

<real

− x *^2 y int int^

int^ int real realF int real real real realreal real Can be used for type inconsistencies/errors

int^ real int real double F int^ realrealrealdouble

double double

double

M. O’Boyle^

Compiler Optimisation

17

Code Generation Typical top down generator - left to right

x^ −^2 ∗^ y

case opgen(left(node), right(node), op(node), nextreg())case identifierreg = nextreg()gen( loadI, offset(node),reg)gen( loadA0, r0,reg,reg)case numgen(loadI, val(node),nextreg()) Optimisations include elimination of redundancy. Unnecessary loadsThis scheme assumes unbounded registers - nextreg() M. O’Boyle^

Compiler Optimisation

18

Code Generation − x *^2

y

5 loadI @x -^43

^ r^

loadA0 r0,r1 -

^ r1^1 loadI 2 ->^

r2^2 loadI @y ->

r3^3 loadA0 r0,r3 -

r3^3 mult r2,r3 -

^ r3^4 sub r1,r3->

r3^5

3 registers used M. O’Boyle^

Compiler Optimisation

20

Machine models/ Optimisation goals In first part of course^ •^ Assume uni-processor with instruction level parallelism, registers and memory^ •^ Generated assembler should not perform any redundant computation^ •^ Should utilise all available functional units and minimise impact of latency^ •^ Register access is fast compared to memory but limited in number. Use wisely^ •^ Two flavours considered superscalar out-of-order vs VLIW: Dynamic vs staticschedulingLater consider multi-core architecture M. O’Boyle^

Compiler Optimisation

21

Summary

-^ Compilation as translation and optimisation •^ Compiler structure •^ Phase order lexical, syntactic, semantic analysis •^ Naive code generation and optimisation •^ Next lecture course work •^ Monday next week lecture postponed •^ Then scalar optimisation - middle end M. O’Boyle^

Compiler Optimisation