Dataflow analysis.

Slides:



Advertisements
Similar presentations
Continuing Abstract Interpretation We have seen: 1.How to compile abstract syntax trees into control-flow graphs 2.Lattices, as structures that describe.
Advertisements

School of EECS, Peking University “Advanced Compiler Techniques” (Fall 2011) SSA Guo, Yao.
Data-Flow Analysis Framework Domain – What kind of solution is the analysis looking for? Ex. Variables have not yet been defined – Algorithm assigns a.
CS412/413 Introduction to Compilers Radu Rugina Lecture 37: DU Chains and SSA Form 29 Apr 02.
Components of representation Control dependencies: sequencing of operations –evaluation of if & then –side-effects of statements occur in right order Data.
Program Representations. Representing programs Goals.
Example in SSA X := Y op Z in out F X := Y op Z (in) = in [ { X ! Y op Z } X :=  (Y,Z) in 0 out F X :=   (in 0, in 1 ) = (in 0 Å in 1 ) [ { X ! E |
6/9/2015© Hal Perkins & UW CSEU-1 CSE P 501 – Compilers SSA Hal Perkins Winter 2008.
CSE 231 : Advanced Compilers Building Program Analyzers.
CSE 231 : Advanced Compilers Building Program Analyzers.
Common Sub-expression Elim Want to compute when an expression is available in a var Domain:
Worklist algorithm Initialize all d i to the empty set Store all nodes onto a worklist while worklist is not empty: –remove node n from worklist –apply.
Recap from last time We were trying to do Common Subexpression Elimination Compute expressions that are available at each program point.
Representing programs Goals. Representing programs Primary goals –analysis is easy and effective just a few cases to handle directly link related things.
Recap from last time Saw several examples of optimizations –Constant folding –Constant Prop –Copy Prop –Common Sub-expression Elim –Partial Redundancy.
CS 536 Spring Global Optimizations Lecture 23.
Correctness. Until now We’ve seen how to define dataflow analyses How do we know our analyses are correct? We could reason about each individual analysis.
Administrative info Subscribe to the class mailing list –instructions are on the class web page, click on “Course Syllabus” –if you don’t subscribe by.
From last time: live variables Set D = 2 Vars Lattice: (D, v, ?, >, t, u ) = (2 Vars, µ, ;,Vars, [, Å ) x := y op z in out F x := y op z (out) = out –
Global optimization. Data flow analysis To generate better code, need to examine definitions and uses of variables beyond basic blocks. With use- definition.
Administrative info Subscribe to the class mailing list –instructions are on the class web page, which is accessible from my home page, which is accessible.
From last time: Lattices A lattice is a tuple (S, v, ?, >, t, u ) such that: –(S, v ) is a poset – 8 a 2 S. ? v a – 8 a 2 S. a v > –Every two elements.
Data Flow Analysis Compiler Design Nov. 3, 2005.
From last time: reaching definitions For each use of a variable, determine what assignments could have set the value being read from the variable Information.
4/25/08Prof. Hilfinger CS164 Lecture 371 Global Optimization Lecture 37 (From notes by R. Bodik & G. Necula)
Constraints for reaching definitions Using may-point-to information: out = in [ { x ! s | x 2 may-point-to(p) } Using must-point-to aswell: out = in –
Another example p := &x; *p := 5 y := x + 1;. Another example p := &x; *p := 5 y := x + 1; x := 5; *p := 3 y := x + 1; ???
Back to lattice (D, v, ?, >, t, u ) = (2 A, ¶, A, ;, Å, [ ) where A = { x ! N | x 2 Vars Æ N 2 Z } What’s the problem with this lattice? Lattice is infinitely.
Class canceled next Tuesday. Recap: Components of IR Control dependencies: sequencing of operations –evaluation of if & then –side-effects of statements.
Administrative stuff Office hours: After class on Tuesday.
Recap Let’s do a recap of what we’ve seen so far Started with worklist algorithm for reaching definitions.
Constraints for reaching definitions Using may-point-to information: out = in [ { x ! s | x 2 may-point-to(p) } Using must-point-to aswell: out = in –
San Diego October 4-7, 2006 Over 1,000 women in computing Events for undergraduates considering careers and graduate school Events for graduate students.
Recap: Reaching defns algorithm From last time: reaching defns worklist algo We want to avoid using structure of the domain outside of the flow functions.
Prof. Fateman CS 164 Lecture 221 Global Optimization Lecture 22.
From last lecture x := y op z in out F x := y op z (in) = in [ x ! in(y) op in(z) ] where a op b =
Direction of analysis Although constraints are not directional, flow functions are All flow functions we have seen so far are in the forward direction.
Common Sub-expression Elim Want to compute when an expression is available in a var Domain:
Projects. Dataflow analysis Dataflow analysis: what is it? A common framework for expressing algorithms that compute information about a program Why.
Recap from last time: live variables x := 5 y := x + 2 x := x + 1 y := x y...
Machine-Independent Optimizations Ⅰ CS308 Compiler Theory1.
From last time: reaching definitions For each use of a variable, determine what assignments could have set the value being read from the variable Information.
Global optimization. Data flow analysis To generate better code, need to examine definitions and uses of variables beyond basic blocks. With use- definition.
From last lecture We want to find a fixed point of F, that is to say a map m such that m = F(m) Define ?, which is ? lifted to be a map: ? = e. ? Compute.
Direction of analysis Although constraints are not directional, flow functions are All flow functions we have seen so far are in the forward direction.
Even more formal To reason more formally about termination and precision, we re-express our worklist algorithm mathematically We will use fixed points.
Recap from last time We saw various different issues related to program analysis and program transformations You were not expected to know all of these.
Termination Still, it’s annoying to have to perform a join in the worklist algorithm It would be nice to get rid of it, if there is a property of the flow.
Prof. Bodik CS 164 Lecture 16, Fall Global Optimization Lecture 16.
Precision Going back to constant prop, in what cases would we lose precision?
Example x := read() v := a + b x := x + 1 w := x + 1 a := w v := a + b z := x + 1 t := a + b.
Dataflow Analysis Topic today Data flow analysis: Section 3 of Representation and Analysis Paper (Section 3) NOTE we finished through slide 30 on Friday.
Formalization of DFA using lattices. Recall worklist algorithm let m: map from edge to computed value at edge let worklist: work list of nodes for each.
Program Representations. Representing programs Goals.
1 Control Flow Graphs. 2 Optimizations Code transformations to improve program –Mainly: improve execution time –Also: reduce program size Can be done.
Lub and glb Given a poset (S, · ), and two elements a 2 S and b 2 S, then the: –least upper bound (lub) is an element c such that a · c, b · c, and 8 d.
Data Flow Analysis Suman Jana
Dataflow analysis.
Program Representations
Topic 10: Dataflow Analysis
University Of Virginia
Another example: constant prop
Optimizations using SSA
Data Flow Analysis Compiler Design
Formalization of DFA using lattices
Formalization of DFA using lattices
Live variables and copy propagation
Formalization of DFA using lattices
Formalization of DFA using lattices
CSE P 501 – Compilers SSA Hal Perkins Autumn /31/2019
Presentation transcript:

Dataflow analysis

Dataflow analysis: what is it? A common framework for expressing algorithms that compute information about a program Why is such a framework useful?

Dataflow analysis: what is it? A common framework for expressing algorithms that compute information about a program Why is such a framework useful? Provides a common language, which makes it easier to: communicate your analysis to others compare analyses adapt techniques from one analysis to another reuse implementations (eg: dataflow analysis frameworks)

Control Flow Graphs For now, we will use a Control Flow Graph representation of programs each statement becomes a node edges between nodes represent control flow Later we will see other program representations variations on the CFG (eg CFG with basic blocks) other graph based representations

Example CFG x := ... y := ... x := ... y := ... p := ... if (...) { } else { *p := ... y := ... p := ... if (...) ... x ... ... x ... x := ... x := ... ... y ... *p := ... ... x ... ... x ... y := ...

An example DFA: reaching definitions For each use of a variable, determine what assignments could have set the value being read from the variable Information useful for: performing constant and copy prop detecting references to undefined variables presenting “def/use chains” to the programmer building other representations, like the DFG Let’s try this out on an example

x := ... Visual sugar y := ... 1: x := ... 2: y := ... 3: y := ... 4: p := ... y := ... p := ... if (...) ... x ... 5: x := ... ... y ... ... x ... 6: x := ... 7: *p := ... ... x ... ... x ... x := ... x := ... ... y ... *p := ... ... x ... ... y ... 8: y := ... ... x ... ... x ... y := ...

1: x := ... 2: y := ... 3: y := ... 4: p := ... ... x ... 5: x := ... ... y ... ... x ... 6: x := ... 7: *p := ... ... x ... ... y ... 8: y := ...

1: x := ... 2: y := ... 3: y := ... 4: p := ... ... x ... 5: x := ... ... y ... ... x ... 6: x := ... 7: *p := ... ... x ... ... y ... 8: y := ...

Safety When is computed info safe? Recall intended use of this info: performing constant and copy prop detecting references to undefined variables presenting “def/use chains” to the programmer building other representations, like the DFG Safety: can have more bindings than the “true” answer, but can’t miss any

Reaching definitions generalized DFA framework geared to computing information at each program point (edge) in the CFG So generalize problem by stating what should be computed at each program point For each program point in the CFG, compute the set of definitions (statements) that may reach that point Notion of safety remains the same

Reaching definitions generalized Computed information at a program point is a set of var ! stmt bindings eg: { x ! s1, x ! s2, y ! s3 } How do we get the previous info we wanted? if a var x is used in a stmt whose incoming info is in, then:

Reaching definitions generalized Computed information at a program point is a set of var ! stmt bindings eg: { x ! s1, x ! s2, y ! s3 } How do we get the previous info we wanted? if a var x is used in a stmt whose incoming info is in, then: { s | (x ! s) 2 in } This is a common pattern generalize the problem to define what information should be computed at each program point use the computed information at the program points to get the original info we wanted

1: x := ... 2: y := ... 3: y := ... 4: p := ... ... x ... 5: x := ... ... y ... ... x ... 6: x := ... 7: *p := ... ... x ... ... y ... 8: y := ...

1: x := ... 2: y := ... 3: y := ... 4: p := ... ... x ... 5: x := ... ... y ... ... x ... 6: x := ... 7: *p := ... ... x ... ... y ... 8: y := ...

Using constraints to formalize DFA Now that we’ve gone through some examples, let’s try to precisely express the algorithms for computing dataflow information We’ll model DFA as solving a system of constraints Each node in the CFG will impose constraints relating information at predecessor and successor points Solution to constraints is result of analysis

Constraints for reaching definitions S: X := ... out in S: *P := ... out

Constraints for reaching definitions S: X := ... out = in – { X ! S’ | S’ 2 stmts } [ { X ! S } out Using may-point-to information: out = in [ { X ! S | X 2 may-point-to(P) } Using must-point-to aswell: out = in – { X ! S’ | X 2 must-point-to(P) Æ S’ 2 stmts } [ { X ! S | X 2 may-point-to(P) } in S: *P := ... out

Constraints for reaching definitions S: if (...) out[0] out[1] in[0] in[1] merge out

Constraints for reaching definitions out [ 0 ] = in Æ out [ 1 ] = in S: if (...) out[0] out[1] more generally: 8 i . out [ i ] = in in[0] in[1] out = in [ 0 ] [ in [ 1 ] merge more generally: out =  i in [ i ] out

Flow functions The constraint for a statement kind s often have the form: out = Fs(in) Fs is called a flow function other names for it: dataflow function, transfer function Given information in before statement s, Fs(in) returns information after statement s Other formulations have the statement s as an explicit parameter to F: given a statement s and some information in, F(s,in) returns the outgoing information after statement s

Flow functions, some issues Issue: what does one do when there are multiple input edges to a node? Issue: what does one do when there are multiple outgoing edges to a node?

Flow functions, some issues Issue: what does one do when there are multiple input edges to a node? the flow functions takes as input a tuple of values, one value for each incoming edge Issue: what does one do when there are multiple outgoing edges to a node? the flow function returns a tuple of values, one value for each outgoing edge can also have one flow function per outgoing edge

Flow functions Flow functions are a central component of a dataflow analysis They state constraints on the information flowing into and out of a statement This version of the flow functions is local it applies to a particular statement kind we’ll see global flow functions shortly...

Summary of flow functions Flow functions: Given information in before statement s, Fs(in) returns information after statement s Flow functions are a central component of a dataflow analysis They state constraints on the information flowing into and out of a statement

Back to example How to find solutions for di? d0 1: x := ... 2: y := ... 3: y := ... 4: p := ... if(...) d1 = Fa(d0) d1 d2 = Fb(d1) d2 d3 = Fc(d2) d3 d4 = Fd(d3) d4 d9 = Ff(d4) d5 = Fe(d4) d9 d5 d10 = Fj(d9) ... x ... 5: x := ... ... y ... ... x ... 6: x := ... 7: *p := ... d6 = Fg(d5) d10 d6 d11 = Fk(d10) d7 = Fh(d6) d11 d7 d12 = Fl(d11) d8 = Fi(d7) d12 d8 d13 = Fm(d12, d8) merge ... x ... ... y ... 8: y := ... How to find solutions for di? d13 d14 = Fn(d13) d14 d15 = Fo(d14) d15 d16 = Fp(d15) d16

How to find solutions for di? This is a forward problem given information flowing in to a node, can determine using the flow function the info flow out of the node To solve, simply propagate information forward through the control flow graph, using the flow functions What are the problems with this approach?

First problem What about the incoming information? d0 1: x := ... 2: y := ... 3: y := ... 4: p := ... if(...) d1 = Fa(d0) d1 d2 = Fb(d1) d2 d3 = Fc(d2) d3 d4 = Fd(d3) d4 d9 = Ff(d4) d5 = Fe(d4) d9 d5 d10 = Fj(d9) ... x ... 5: x := ... ... y ... ... x ... 6: x := ... 7: *p := ... d6 = Fg(d5) d10 d6 d11 = Fk(d10) d7 = Fh(d6) d11 d7 d12 = Fl(d11) d8 = Fi(d7) d12 d8 d13 = Fm(d12, d8) merge ... x ... ... y ... 8: y := ... What about the incoming information? d13 d14 = Fn(d13) d14 d15 = Fo(d14) d15 d16 = Fp(d15) d16

First problem What about the incoming information? d0 is not constrained so where do we start? Need to constrain d0 Two options: explicitly state entry information have an entry node whose flow function sets the information on entry (doesn’t matter if entry node has an incoming edge, its flow function ignores any input)

Entry node S: entry out = { X ! S | X 2 Formals } out

Second problem Which order to process nodes in? d0 = Fentry() d0 1: x := ... 2: y := ... 3: y := ... 4: p := ... if(...) d1 = Fa(d0) d1 d2 = Fb(d1) d2 d3 = Fc(d2) d3 d4 = Fd(d3) d4 d9 = Ff(d4) d5 = Fe(d4) d9 d5 d10 = Fj(d9) ... x ... 5: x := ... ... y ... ... x ... 6: x := ... 7: *p := ... d6 = Fg(d5) d10 d6 d11 = Fk(d10) d7 = Fh(d6) d11 d7 d12 = Fl(d11) d8 = Fi(d7) d12 d8 d13 = Fm(d12, d8) Which order to process nodes in? merge ... x ... ... y ... 8: y := ... d13 d14 = Fn(d13) d14 d15 = Fo(d14) d15 d16 = Fp(d15) d16

Second problem Which order to process nodes in? Sort nodes in topological order each node appears in the order after all of its predecessors Just run the flow functions for each of the nodes in the topological order What’s the problem now?

Second problem, prime When there are loops, there is no topological order! What to do? Let’s try and see what we can do

1: x := ... 2: y := ... 3: y := ... 4: p := ... ... x ... 5: x := ... ... y ... ... x ... 6: x := ... 7: *p := ... ... x ... ... y ... 8: y := ...

1: x := ... 2: y := ... 3: y := ... 4: p := ... ... x ... 5: x := ... ... y ... ... x ... 6: x := ... 7: *p := ... ... x ... ... y ... 8: y := ...

Worklist algorithm Initialize all di to the empty set Store all nodes onto a worklist while worklist is not empty: remove node n from worklist apply flow function for node n update the appropriate di, and add nodes whose inputs have changed back onto worklist

Worklist algorithm let m: map from edge to computed value at edge let worklist: work list of nodes for each edge e in CFG do m(e) := ; for each node n do worklist.add(n) while (worklist.empty.not) do let n := worklist.remove_any; let info_in := m(n.incoming_edges); let info_out := F(n, info_in); for i := 0 .. info_out.length-1 do if (m(n.outgoing_edges[i])  info_out[i]) m(n.outgoing_edges[i]) := info_out[i]; worklist.add(n.outgoing_edges[i].dst);

Issues with worklist algorithm

Two issues with worklist algorithm Ordering In what order should the original nodes be added to the worklist? What order should nodes be removed from the worklist? Does this algorithm terminate?

Order of nodes Topological order assuming back-edges have been removed Reverse depth-first post-order Use an ordered worklist

1: x := ... 2: y := ... 3: y := ... 4: p := ... ... x ... 5: x := ... ... y ... ... x ... 6: x := ... 7: *p := ... ... x ... ... y ... 8: y := ...

Termination Why is termination important? Can we stop the algorithm in the middle and just say we’re done... No: we need to run it to completion, otherwise the results are not safe...

Termination Assuming we’re doing reaching defs, let’s try to guarantee that the worklist loop terminates, regardless of what the flow function F does while (worklist.empty.not) do let n := worklist.remove_any; let info_in := m(n.incoming_edges); let info_out := F(n, info_in); for i := 0 .. info_out.length-1 do if (m(n.outgoing_edges[i])  info_out[i]) m(n.outgoing_edges[i]) := info_out[i]; worklist.add(n.outgoing_edges[i].dst);

Termination Assuming we’re doing reaching defs, let’s try to guarantee that the worklist loop terminates, regardless of what the flow function F does while (worklist.empty.not) do let n := worklist.remove_any; let info_in := m(n.incoming_edges); let info_out := F(n, info_in); for i := 0 .. info_out.length-1 do let new_info := m(n.outgoing_edges[i]) [ info_out[i]; if (m(n.outgoing_edges[i])  new_info]) m(n.outgoing_edges[i]) := new_info; worklist.add(n.outgoing_edges[i].dst);

Structure of the domain We’re using the structure of the domain outside of the flow functions In general, it’s useful to have a framework that formalizes this structure We will use lattices