introduction to compilers n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Introduction to Compilers PowerPoint Presentation
Download Presentation
Introduction to Compilers

Loading in 2 Seconds...

play fullscreen
1 / 44

Introduction to Compilers - PowerPoint PPT Presentation


  • 110 Views
  • Uploaded on

Introduction to Compilers. Ben Livshits. Based in part of Stanford class slides from http ://infolab.stanford.edu /~ ullman/dragon/w06/w06.html . My Lectures. reliability & bug finding. performance. security. Lecture 1 : Introduction to static analysis

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Introduction to Compilers


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
introduction to compilers

Introduction to Compilers

Ben Livshits

Based in part of Stanford class slides from

http://infolab.stanford.edu/~ullman/dragon/w06/w06.html

my lectures
My Lectures

reliability & bug finding

performance

security

Lecture 1: Introduction to staticanalysis

Lecture 2: Introduction to runtimeanalysis

Lecture 3: Applicationsof static and runtime analysis

l1 lecture organization
L1: Lecture Organization
  • Really basic stuff
    • Flow Graphs
    • Constant Folding
    • Global Common Subexpression Elimination
  • Data-flow analysis
    • Proving Little Theorems
    • Data-Flow Equations
    • Major Examples: reaching definitions
  • Looking forward…
dawn of code optimization
Dawn of Code Optimization

A never-published Stanford technical report by Fran Allen in 1968

Flow graphs of intermediate code

stages of compilation
Stages of Compilation

Source code

Lexing

Parsing

IR

Analysis

Code generation

Executable code

stages of compilation1
Stages of Compilation

Source code

Lexing

Parsing

IR

Analysis

Code generation

Executable code

stages of compilation2
Stages of Compilation

Source code

Lexing

Parsing

IR

Analysis

Code generation

Executable code

stages of compilation3
Stages of Compilation

Source code

Lexing

Parsing

IR

Analysis

Code generation

Executable code

stages of compilation4
Stages of Compilation

Source code

Lexing

Parsing

IR

Analysis

Code generation

Executable code

stages of compilation5
Stages of Compilation

Source code

Lexing

Parsing

IR

Analysis

Code generation

Executable code

intermediate code

i = 0

if i>=n goto …

t1 = 8*i

A[t1] = 1

i = i+1

Intermediate Code

for (i=0; i<n; i++)

A[i] = 1;

Make flow explicit by breaking into basic blocks= sequences of steps with entry at beginning, exit at end

Intermediate code exposes optimizable constructs we cannot see at source-code level

constant folding
Constant Folding

Sometimes a variable has a known constant value at a point

If so, replacing the variable by the constant simplifies and speeds-up the code

Easy within a basic block; harder across blocks

constant folding example

i = 0

n = 100

if i>=n goto …

t1 = 8*i

A[t1] = 1

i = i+1

Constant Folding Example

t1 = 0

if t1>=800 goto …

A[t1] = 1

t1 = t1+8

global common subexpressions
Global Common Subexpressions
  • Suppose block B has a computation of x+y
  • Suppose we are sure that when we reach this computation, we are sure to have:
    • Computed x+y, and
    • Not subsequently reassigned x or y
  • Then we can hold the value of x+yand use it in B
gcse example

a = x+y

t = x+y

a = t

b = x+y

t = x+y

b = t

c = x+y

c = t

GCSE Example
example even better

t = x+y

a = t

t = x+y

b = t

c = t

Example: Even Better

t = x+y

a = t

b = t

t = x+y

b = t

c = t

data flow analysis
Data-Flow Analysis
  • Proving Little Theorems
  • Data-Flow Equations
  • Major Examples: reaching definitions
an obvious theorem
An Obvious Theorem

boolean x = true;

while (x) {

. . . // no change to x

}

Let’s prove that this loop doesn’t terminate

Proof: only assignment to x is at top, so x is always true

as a flow graph
As a Flow Graph

x = true

if x == true

“body”

formulation reaching definitions
Formulation: Reaching Definitions

Each place some variable x is assigned is a definition

Ask: for this use of x, where could x last have been defined

In our example: only at x=true

example reaching definitions

d2

d1

Example: Reaching Definitions

d1: x = true

d1

d2

if x == true

d1

d2: a = 10

clincher
Clincher

Since at x == true, d1is the only definition of x that reaches, it must be that x is true at that point

The conditional is not really a conditional and can be replaced by a branch

not always that easy
Not Always That Easy

int i = 2;

intj = 3;

while (i != j) {

if (i < j) i += 2;

else j += 2;

}

We’ll develop techniques for this problem, but later …

the flow graph

d1

d2

d3

d4

d2, d3, d4

d1, d3, d4

d1, d2, d3, d4

d1, d2, d3, d4

The Flow Graph

d1: i = 2

d2: j = 3

if i != j

d1, d2, d3, d4

if i < j

d3: i = i+2

d4: j = j+2

dfa is sometimes insufficient
DFA Is Sometimes Insufficient

In this example, i can be defined in two places, and j in two places

No obvious way to discover that i!=jis always true

But OK, because reaching definitions is sufficient to catch most opportunities for constant folding(replacement of a variable by its only possible value)

be conservative
Be Conservative!

It’s OK to discover a subset of the opportunities to make some code-improving transformation.

It’s not OK to think you have an opportunity that you don’t really have.

Must we always be conservative?

example be conservative
Example: Be Conservative

boolean x = true;

while (x) {

. . . *p = false; . . .

}

Is it possible that p points to x?

as a flow graph1

Another

def of x

d2

As a Flow Graph

d1: x = true

d1

if x == true

d2: *p = false

possible resolution
Possible Resolution

Just as data-flow analysis of “reaching definitions” can tell what definitions of x might reach a point, another DFA can eliminate cases where p definitely does not point to x

Example: in a C program the only definition of p is p = &yand there is no possibility that y is an alias of x

reaching definitions formalized
Reaching Definitions Formalized
  • A definition d of a variable x is said to reach a point p in a flow graph if:
    • Every path from the entry of the flow graph to p has d on the path, and
    • After the last occurrence of d there is no possibility that x is redefined
data flow equations 1
Data-Flow Equations: (1)
  • A basic block can generate a definition
  • A basic block can either
    • Killa definition of x if it surely redefines x
    • Transmit a definition if it may not redefine the same variable(s) as that definition
data flow equations 2
Data-Flow Equations: (2)
  • Variables:
    • IN(B) = set of definitions reaching the beginning of block B.
    • OUT(B) = set of definitions reaching the end of B.
data flow equations 3
Data-Flow Equations: (3)
  • Two kinds of equations:
    • Confluence equations: IN(B) in terms of outs of predecessors of B
    • Transfer equations: OUT(B) in terms of of IN(B) and what goes on in block B.
confluence equations

{d1, d2}

{d2, d3}

Confluence Equations

P1

P2

{d1, d2, d3}

B

IN(B) = ∪predecessors P of B OUT(P)

transfer equations
Transfer Equations

Generate a definition in the block if its variable is not definitely rewritten later in the basic block.

Killa definition if its variable is definitely rewritten in the block.

An internal definition may be both killed and generated.

example gen and kill
Example: Gen and Kill

IN = {d2(x), d3(y), d3(z), d5(y), d6(y), d7(z)}

Kill includes {d1(x), d2(x),

d3(y), d5(y), d6(y),…}

d1: y = 3

d2: x = y+z

d3: *p = 10

d4: y = 5

Gen = {d2(x), d3(x),

d3(z),…, d4(y)}

OUT = {d2(x), d3(x), d3(z),…, d4(y), d7(z)}

transfer function for a block
Transfer Function for a Block

For any block B:

OUT(B) = (IN(B) – Kill(B)) ∪Gen(B)

iterative solution to equations
Iterative Solution to Equations

For an n-block flow graph, there are 2n equations in 2n unknowns

Alas, the solution is not unique

Use iteration to get the least fixed-point

Has nice performance guarantees

iterative solution 2
Iterative Solution: (2)

IN(entry) = ∅;

for each block B do OUT(B)= ∅;

while (changes occur) do

for each block B do {

IN(B) = ∪predecessors P of B OUT(P);

OUT(B) = (IN(B) – Kill(B)) ∪Gen(B);

}

example reaching definitions1

IN(B1) = {}

OUT(B1) = {

IN(B2) = {

d1,

OUT(B2) = {

IN(B3) = {

d1,

OUT(B3) = {

Example: Reaching Definitions

d1: x = 5

B1

d1}

d2}

if x == 10

B2

d1,

d2}

d2}

d2: x = 15

B3

d2}

notice the conservatism
Notice the Conservatism

Not only the most conservative assumption about when a def is killed or gen’d

Also the conservative assumption that any path in the flow graph can actually be taken

Must we always be conservative?

where are we going from here
Where are we Going From Here?
  • Inter-procedural analysis
  • Context-sensitive analysis
  • Object-sensitive analysis
  • Pointers or references
  • Reflection
  • Dynamic code generation

research

Some is covered in Yannis’s lectures…

a little javascript program
A Little JavaScript Program

f = function(x){ return x+1; }

function compose(){

return function(x){

return f(f(x)) }; }

compose(f)(3);

this[‘compose’](f)(3)

this['comp' + 'os' + ("E".toLowerCase())](f)(3)

function(f){ return ;

eval("compose(f)(" + arguments[0] + ");"); }()(3);