CSC D70: Compiler Optimization Dataflow-2 and Loops

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

Data-Flow Analysis II CS 671 March 13, CS 671 – Spring Data-Flow Analysis Gather conservative, approximate information about what a program.
Chapter 9 Code optimization Section 0 overview 1.Position of code optimizer 2.Purpose of code optimizer to get better efficiency –Run faster –Take less.
Jeffrey D. Ullman Stanford University. 2  A set of nodes N and edges E is a region if: 1.There is a header h in N that dominates all nodes in N. 2.If.
Data-Flow Analysis Framework Domain – What kind of solution is the analysis looking for? Ex. Variables have not yet been defined – Algorithm assigns a.
1 Code Optimization. 2 The Code Optimizer Control flow analysis: control flow graph Data-flow analysis Transformations Front end Code generator Code optimizer.
School of EECS, Peking University “Advanced Compiler Techniques” (Fall 2011) Dataflow Analysis Introduction Guo, Yao Part of the slides are adapted from.
A Deeper Look at Data-flow Analysis Copyright 2011, Keith D. Cooper & Linda Torczon, all rights reserved. Students enrolled in Comp 512 at Rice University.
1 CS 201 Compiler Construction Data Flow Framework.
1 Data flow analysis Goal : collect information about how a procedure manipulates its data This information is used in various optimizations For example,
1 CS 201 Compiler Construction Lecture 2 Control Flow Analysis.
Jeffrey D. Ullman Stanford University Flow Graph Theory.
Foundations of Data-Flow Analysis. Basic Questions Under what circumstances is the iterative algorithm used in the data-flow analysis correct? How precise.
1 CS 201 Compiler Construction Lecture 2 Control Flow Analysis.
1 Data flow analysis Goal : –collect information about how a procedure manipulates its data This information is used in various optimizations –For example,
Global optimization. Data flow analysis To generate better code, need to examine definitions and uses of variables beyond basic blocks. With use- definition.
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.
1 CS 201 Compiler Construction Lecture 3 Data Flow Analysis.
Data Flow Analysis Compiler Design October 5, 2004 These slides live on the Web. I obtained them from Jeff Foster and he said that he obtained.
CS 412/413 Spring 2007Introduction to Compilers1 Lecture 29: Control Flow Analysis 9 Apr 07 CS412/413 Introduction to Compilers Tim Teitelbaum.
Data Flow Analysis Compiler Design Nov. 8, 2005.
Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs, Data-flow Analysis Data-flow Frameworks --- today’s.
San Diego October 4-7, 2006 Over 1,000 women in computing Events for undergraduates considering careers and graduate school Events for graduate students.
1 Data-Flow Frameworks Lattice-Theoretic Formulation Meet-Over-Paths Solution Monotonicity/Distributivity.
U NIVERSITY OF M ASSACHUSETTS, A MHERST D EPARTMENT OF C OMPUTER S CIENCE Advanced Compilers CMPSCI 710 Spring 2003 Data flow analysis Emery Berger University.
1 CS 201 Compiler Construction Lecture 4 Data Flow Framework.
School of EECS, Peking University “Advanced Compiler Techniques” (Fall 2011) Loops Guo, Yao.
Machine-Independent Optimizations Ⅰ CS308 Compiler Theory1.
Global optimization. Data flow analysis To generate better code, need to examine definitions and uses of variables beyond basic blocks. With use- definition.
Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs Data-flow Analysis: Data-flow frameworks –Classic.
Prof. Bodik CS 164 Lecture 16, Fall Global Optimization Lecture 16.
Λλ Fernando Magno Quintão Pereira P ROGRAMMING L ANGUAGES L ABORATORY Universidade Federal de Minas Gerais - Department of Computer Science P ROGRAM A.
1 Region-Based Data Flow Analysis. 2 Loops Loops in programs deserve special treatment Because programs spend most of their time executing loops, improving.
1 CS 201 Compiler Construction Data Flow Analysis.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Instructor Kostas Kontogiannis.
1 Code Optimization Chapter 9 (1 st ed. Ch.10) COP5621 Compiler Construction Copyright Robert van Engelen, Florida State University,
Dataflow Analysis Topic today Data flow analysis: Section 3 of Representation and Analysis Paper (Section 3) NOTE we finished through slide 30 on Friday.
Jeffrey D. Ullman Stanford University. 2 boolean x = true; while (x) {... // no change to x }  Doesn’t terminate.  Proof: only assignment to x is at.
Global Redundancy Elimination: Computing Available Expressions Copyright 2011, Keith D. Cooper & Linda Torczon, all rights reserved. Students enrolled.
1 Data Flow Analysis Data flow analysis is used to collect information about the flow of data values across basic blocks. Dominator analysis collected.
Advanced Compiler Techniques LIU Xianhua School of EECS, Peking University Loops.
Compiler Principles Fall Compiler Principles Lecture 11: Loop Optimizations Roman Manevich Ben-Gurion University.
1 CS 201 Compiler Construction Lecture 2 Control Flow Analysis.
Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs Data-flow Analysis: Data-flow frameworks –Classic.
Data Flow Analysis II AModel Checking and Abstract Interpretation Feb. 2, 2011.
1 Code Optimization Chapter 9 (1 st ed. Ch.10) COP5621 Compiler Construction Copyright Robert van Engelen, Florida State University,
Loops Simone Campanoni
Code Optimization Data Flow Analysis. Data Flow Analysis (DFA)  General framework  Can be used for various optimization goals  Some terms  Basic block.
DFA foundations Simone Campanoni
Data Flow Analysis Suman Jana
CS 201 Compiler Construction
Simone Campanoni DFA foundations Simone Campanoni
Dataflow Testing G. Rothermel.
CSC D70: Compiler Optimization LICM: Loop Invariant Code Motion
CSC D70: Compiler Optimization Dataflow Analysis
Advanced Compiler Techniques
CS 201 Compiler Construction
Code Optimization Chapter 10
Code Optimization Chapter 9 (1st ed. Ch.10)
Another example: constant prop
1. Reaching Definitions Definition d of variable v: a statement d that assigns a value to v. Use of variable v: reference to value of v in an expression.
CSC D70: Compiler Optimization Static Single Assignment (SSA)
Control Flow Analysis (Chapter 7)
Data Flow Analysis Compiler Design
Topic-4a Dataflow Analysis 2019/2/22 \course\cpeg421-08s\Topic4-a.ppt.
Static Single Assignment
CSC D70: Compiler Optimization LICM: Loop Invariant Code Motion
CSC D70: Compiler Optimization Static Single Assignment (SSA)
Presentation transcript:

CSC D70: Compiler Optimization Dataflow-2 and Loops Prof. Gennady Pekhimenko University of Toronto Winter 2018 The content of this lecture is adapted from the lectures of Todd Mowry and Phillip Gibbons

Refreshing from Last Lecture Reaching definitions Live variables

Framework Reaching Definitions Live Variables Domain Sets of definitions Sets of variables Direction forward: out[b] = fb(in[b]) in[b] =  out[pred(b)] backward: in[b] = fb(out[b]) out[b] =  in[succ(b)] Transfer function fb(x) = Genb  (x –Killb) fb(x) = Useb  (x -Defb) Meet Operation ()  Boundary Condition out[entry] =  in[exit] =  Initial interior points out[b] =  in[b] =  Other examples (e.g., Available expressions), defined in ALSU 9.2.6

Questions Correctness Precision: how good is the answer? equations are satisfied, if the program terminates. Precision: how good is the answer? is the answer ONLY a union of all possible executions? Convergence: will the analysis terminate? or, will there always be some nodes that change? Speed: how fast is the convergence? how many times will we visit each node?

Foundations of Data Flow Analysis Meet operator Transfer functions Correctness, Precision, Convergence Efficiency Reference: ALSU pp. 613-631 Background: Hecht and Ullman, Kildall, Allen and Cocke[76] Marlowe & Ryder, Properties of data flow frameworks: a unified model. Rutgers tech report, Apr. 1988

A Unified Framework Data flow problems are defined by Domain of values: V Meet operator (V  V  V), initial value A set of transfer functions (V  V) Usefulness of unified framework To answer questions such as correctness, precision, convergence, speed of convergence for a family of problems If meet operators and transfer functions have properties X, then we know Y about the above. Reuse code

Meet Operator Properties of the meet operator commutative: x  y = y  x idempotent: x  x = x associative: x  (y  z) = (x  y)  z there is a Top element T such that x  T = x Meet operator defines a partial ordering on values x ≤ y if and only if x  y = x (y -> x in diagram) Transitivity: if x ≤ y and y ≤ z then x ≤ z Antisymmetry: if x ≤ y and y ≤ x then x = y Reflexitivity: x ≤ x x y x  y

Partial Order Example: let V = {x | such that x  { d1, d2}},  =  Top and Bottom elements Top T such that: x  T = x Bottom  such that: x   =  Values and meet operator in a data flow problem define a semi-lattice: there exists a T, but not necessarily a . x, y are ordered: x ≤ y then x  y = x (y -> x in diagram) what if x and y are not ordered? x  y ≤ x, x  y ≤ y, and if w ≤ x, w ≤ y, then w ≤ x  y

One vs. All Variables/Definitions Lattice for each variable: e.g. intersection Lattice for three variables: 1

Descending Chain Definition Height of values in reaching definitions? The height of a lattice is the largest number of > relations that will fit in a descending chain. x0 > x1 > x2 > … Height of values in reaching definitions? Important property: finite descending chain Can an infinite lattice have a finite descending chain? Example: Constant Propagation/Folding To determine if a variable is a constant Data values undef, ... -1, 0, 1, 2, ..., not-a-constant Lecture 2 stop Height n – number of definitions yes

Transfer Functions Basic Properties f: V  V Has an identity function There exists an f such that f (x) = x, for all x. Closed under composition if f1, f2  F, then f1  f2  F

Monotonicity A framework (F, V, ) is monotone if and only if x ≤ y implies f(x) ≤ f(y) i.e. a “smaller or equal” input to the same function will always give a “smaller or equal” output Equivalently, a framework (F, V, ) is monotone if and only if f(x  y) ≤ f(x)  f(y) i.e. merge input, then apply f is small than or equal to apply the transfer function individually and then merge the result

Example Reaching definitions: f(x) = Gen  (x - Kill),  =  x1 ≤ x2, Gen  (x1 - Kill) ≤ Gen  (x2 - Kill) Definition 2: (Gen  (x1 - Kill) )  (Gen  (x2 - Kill) ) = (Gen  ((x1  x2) - Kill)) Note: Monotone framework does not mean that f(x) ≤ x e.g., reaching definition for two definitions in program suppose: fx: Genx = {d1, d2} ; Killx= {} If input(second iteration) ≤ input(first iteration) result(second iteration) ≤ result(first iteration)

Distributivity A framework (F, V, ) is distributive if and only if f(x  y) = f(x)  f(y) i.e. merge input, then apply f is equal to apply the transfer function individually then merge result Example: Constant Propagation is NOT distributive a = 2 b = 3 a = 3 b = 2 c = a + b

Data Flow Analysis Definition Ideal data flow answer: Let f1, ..., fm :  F, where fi is the transfer function for node i fp = fnk  …  fn1 , where p is a path through nodes n1, ..., nk fp = identify function, if p is an empty path Ideal data flow answer: For each node n:  fpi (T), for all possibly executed paths pi reaching n. But determining all possibly executed paths is undecidable if sqrt(y) >= 0 x = 0 x = 1

Meet-Over-Paths (MOP) Error in the conservative direction Meet-Over-Paths (MOP): For each node n: MOP(n) =  fpi (T), for all paths pi reaching n a path exists as long there is an edge in the code consider more paths than necessary MOP = Perfect-Solution  Solution-to-Unexecuted-Paths MOP ≤ Perfect-Solution Potentially more constrained, solution is small hence conservative It is not safe to be > Perfect-Solution! Desirable solution: as close to MOP as possible

MOP Example

Solving Data Flow Equations Example: Reaching definitions out[entry] = {} Values = {subsets of definitions} Meet operator:  in[b] =  out[p], for all predecessors p of b Transfer functions: out[b] = genb  (in[b] -killb) Any solution satisfying equations = Fixed Point Solution (FP) Iterative algorithm initializes out[b] to {} if converges, then it computes Maximum Fixed Point (MFP): MFP is the largest of all solutions to equations Properties: FP ≤ MFP ≤ MOP ≤ Perfect-solution FP, MFP are safe in(b) ≤ MOP(b)

Partial Correctness of Algorithm If data flow framework is monotone, then if the algorithm converges, IN[b] ≤ MOP[b] Proof: Induction on path lengths Define IN[entry] = OUT[entry] and transfer function of entry = Identity function Base case: path of length 0 Proper initialization of IN[entry] If true for path of length k, pk = (n1, ..., nk), then true for path of length k+1: pk+1 = (n1, ..., nk+1) Assume: IN[nk] ≤ fnk-1(fnk-2(... fn1(IN[entry]))) IN[nk+1] = OUT[nk]  ... ≤ OUT[nk] ≤ fnk (IN[nk]) ≤ fnk-1(fnk-2(... fn1(IN[entry])))

Precision If data flow framework is distributive,then if the algorithm converges, IN[b] = MOP[b] Monotone but not distributive: behaves as if there are additional paths a = 2 b = 3 a = 3 b = 2 c = a + b

Additional Property to Guarantee Convergence Data flow framework (monotone) converges if there is a finite descending chain For each variable IN[b], OUT[b], consider the sequence of values set to each variable across iterations: if sequence for in[b] is monotonically decreasing sequence for out[b] is monotonically decreasing (out[b] initialized to T) if sequence for out[b] is monotonically decreasing sequence of in[b] is monotonically decreasing

Speed of Convergence Speed of convergence depends on order of node visits Reverse “direction” for backward flow problems

Reverse Postorder Step 1: depth-first post order main() { count = 1; Visit(root); } Visit(n) { for each successor s that has not been visited Visit(s); PostOrder(n) = count; count = count+1; } Step 2: reverse order For each node i rPostOrder = NumNodes - PostOrder(i)

Depth-First Iterative Algorithm (forward) input: control flow graph CFG = (N, E, Entry, Exit) /* Initialize */ out[entry] = init_value For all nodes i out[i] = T Change = True /* iterate */ While Change { Change = False For each node i in rPostOrder { in[i] = (out[p]), for all predecessors p of i oldout = out[i] out[i] = fi(in[i]) if oldout  out[i] }

Speed of Convergence If cycles do not add information information can flow in one pass down a series of nodes of increasing order number: e.g., 1 -> 4 -> 5 -> 7 -> 2 -> 4 ... passes determined by number of back edges in the path essentially the nesting depth of the graph Number of iterations = number of back edges in any acyclic path + 2 (2 are necessary even if there are no cycles) What is the depth? corresponds to depth of intervals for “reducible” graphs in real programs: average of 2.75

A Check List for Data Flow Problems Semi-lattice set of values meet operator top, bottom finite descending chain? Transfer functions function of each basic block monotone distributive? Algorithm initialization step (entry/exit, other nodes) visit order: rPostOrder depth of the graph

Conclusions Dataflow analysis examples Dataflow formation definition Reaching definitions Live variables Dataflow formation definition Meet operator Transfer functions Correctness, Precision, Convergence Efficiency

CSC D70: Compiler Optimization Loops Prof. Gennady Pekhimenko University of Toronto Winter 2018 The content of this lecture is adapted from the lectures of Todd Mowry and Phillip Gibbons

What is a Loop? Goals: Define a loop in graph-theoretic terms (control flow graph) Not sensitive to input syntax A uniform treatment for all loops: DO, while, goto’s Not every cycle is a “loop” from an optimization perspective Intuitive properties of a loop single entry point edges must form at least a cycle Is this a loop? Is this a loop?

Formal Definitions Dominators Node d dominates node n in a graph (d dom n) if every path from the start node to n goes through d Dominators can be organized as a tree a ->b in the dominator tree iff a immediately dominates b

15-745 SSA Dominance 1 1 11 5 6 7 8 2 3 4 9 10 12 13 2 5 9 11 6 7 10 3 12 8 4 13 CFG D-Tree x strictly dominates w (x sdom w) iff x dom w AND x  w © Seth Copen Goldstein & Todd C. Mowry 2001-3

Natural Loops Definitions Single entry-point: header a header dominates all nodes in the loop A back edge is an arc whose head dominates its tail (tail -> head) a back edge must be a part of at least one loop The natural loop of a back edge is the smallest set of nodes that includes the head and tail of the back edge, and has no predecessors outside the set, except for the predecessors of the header.

Natural Loops - Example

Algorithm to Find Natural Loops Find the dominator relations in a flow graph Identify the back edges Find the natural loop associated with the back edge

1. Finding Dominators Definition Formulated as MOP problem: Speed: Node d dominates node n in a graph (d dom n) if every path from the start node to n goes through d Formulated as MOP problem: node d lies on all possible paths reaching node n  d dom n Direction: Values: Meet operator: Top: Bottom: Boundary condition: start/entry node = Initialization for internal nodes Finite descending chain? Transfer function: Speed: With reverse postorder, most flow graphs (reducible flow graphs) converge in 1 pass forward basic blocks ∩ all basic blocks {} OUT[entry]= {entry} OUT[b]= Top Yes (depth=number of basic blocks) F_b(x) = b ∪ {x}

Example

2. Finding Back Edges Depth-first spanning tree Edges traversed in a depth-first search of the flow graph form a depth-first spanning tree Categorizing edges in graph Advancing (A) edges: from ancestor to proper descendant Cross (C) edges: from right to left Retreating (R) edges: from descendant to ancestor (not necessarily proper)

Back Edges Definition Relationships between graph edges and back edges Back edge: t->h, h dominates t Relationships between graph edges and back edges Algorithm Perform a depth first search For each retreating edge t->h, check if h is in t’s dominator list Most programs (all structured code, and most GOTO programs) have reducible flow graphs retreating edges = back edges

Examples

3. Constructing Natural Loops The natural loop of a back edge is the smallest set of nodes that includes the head and tail of the back edge, and has no predecessors outside the set, except for the predecessors of the header. Algorithm delete h from the flow graph find those nodes that can reach t (those nodes plus h form the natural loop of t -> h) 1. Entire graph, 2. {2-8}, 3. {4,6}

Inner Loops If two loops do not have the same header: they are either disjoint, or one is entirely contained (nested within) the other inner loop: one that contains no other loop. If two loops share the same header: Hard to tell which is the inner loop Combine as one

Preheader Optimizations often require code to be executed once before the loop Create a preheader basic block for every loop

Finding Loops: Summary Define loops in graph theoretic terms Definitions and algorithms for: Dominators Back edges Natural loops

CSC D70: Compiler Optimization Dataflow-2 and Loops Prof. Gennady Pekhimenko University of Toronto Winter 2018 The content of this lecture is adapted from the lectures of Todd Mowry and Phillip Gibbons

Backup Slides

Dominance Frontier The Dominance Frontier of a node x = 15-745 SSA Dominance Frontier 1 1 2 2 4 5 9 5 9 12 13 11 6 7 10 3 6 7 8 10 11 3 12 8 4 The Dominance Frontier of a node x = { w | x dom pred(w) AND !(x sdom w)} 13 CFG D-Tree x strictly dominates w (x sdom w) iff x dom w AND x  w © Seth Copen Goldstein & Todd C. Mowry 2001-3

Dominance Frontier and Path Convergence 15-745 SSA Dominance Frontier and Path Convergence 1 1 2 5 9 2 5 9 11 6 7 10 11 3 6 7 10 3 12 8 12 8 4 4 13 13 © Seth Copen Goldstein & Todd C. Mowry 2001-3