Jeffrey D. Ullman Stanford University. 2  Generalizes: 1.Moving loop-invariant computations outside the loop. 2.Eliminating common subexpressions. 3.True.

Slides:



Advertisements
Similar presentations
Data-Flow Analysis II CS 671 March 13, CS 671 – Spring Data-Flow Analysis Gather conservative, approximate information about what a program.
Advertisements

Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs Data-flow Analysis – today’s class –Classic analyses.
P3 / 2004 Register Allocation. Kostis Sagonas 2 Spring 2004 Outline What is register allocation Webs Interference Graphs Graph coloring Spilling Live-Range.
Lecture 11: Code Optimization CS 540 George Mason University.
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.
1 CS 201 Compiler Construction Lecture 3 Data Flow Analysis.
Architecture-dependent optimizations Functional units, delay slots and dependency analysis.
Jeffrey D. Ullman Stanford University. 2  A never-published Stanford technical report by Fran Allen in  Fran won the Turing award in  Flow.
Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs Data-flow Analysis – today’s class –Classic analyses.
Advanced Compiler Techniques LIU Xianhua School of EECS, Peking University Partial Redundancy Elimination.
School of EECS, Peking University “Advanced Compiler Techniques” (Fall 2011) Dataflow Analysis Introduction Guo, Yao Part of the slides are adapted from.
1 CS 201 Compiler Construction Lecture 7 Code Optimizations: Partial Redundancy Elimination.
1 Partial Redundancy Elimination Finding the Right Place to Evaluate Expressions Four Necessary Data-Flow Problems.
School of EECS, Peking University “Advanced Compiler Techniques” (Fall 2011) Partial Redundancy Elimination Guo, Yao.
Lazy Code Motion Comp 512 Spring 2011
Partial Redundancy Elimination & Lazy Code Motion
Lazy Code Motion C OMP 512 Rice University Houston, Texas Fall 2003 Copyright 2003, Keith D. Cooper & Linda Torczon, all rights reserved. Students enrolled.
Λλ Fernando Magno Quintão Pereira P ROGRAMMING L ANGUAGES L ABORATORY Universidade Federal de Minas Gerais - Department of Computer Science P ROGRAM A.
Partial Redundancy Elimination. Partial-Redundancy Elimination Minimize the number of expression evaluations By moving around the places where an expression.
1 Data flow analysis Goal : collect information about how a procedure manipulates its data This information is used in various optimizations For example,
1 Copy Propagation What does it mean? Given an assignment x = y, replace later uses of x with uses of y, provided there are no intervening assignments.
1 CS 201 Compiler Construction Lecture 5 Code Optimizations: Copy Propagation & Elimination.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts, Amherst Advanced Compilers CMPSCI 710.
More Dataflow Analysis CS153: Compilers Greg Morrisett.
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.
4/25/08Prof. Hilfinger CS164 Lecture 371 Global Optimization Lecture 37 (From notes by R. Bodik & G. Necula)
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.
1 Copy Propagation What does it mean? – Given an assignment x = y, replace later uses of x with uses of y, provided there are no intervening assignments.
Topic 6 -Code Generation Dr. William A. Maniatty Assistant Prof. Dept. of Computer Science University At Albany CSI 511 Programming Languages and Systems.
2015/6/29\course\cpeg421-08s\Topic4-a.ppt1 Topic-I-C Dataflow Analysis.
School of EECS, Peking University “Advanced Compiler Techniques” (Fall 2011) Loops Guo, Yao.
Machine-Independent Optimizations Ⅰ CS308 Compiler Theory1.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts, Amherst Advanced Compilers CMPSCI 710.
Global optimization. Data flow analysis To generate better code, need to examine definitions and uses of variables beyond basic blocks. With use- definition.
Ben Livshits Based in part of Stanford class slides from
Eliminating Memory References Joshua Dunfield Alina Oprea.
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 Data-Flow Analysis Proving Little Theorems Data-Flow Equations Major Examples.
What’s in an optimizing compiler?
Formal Methods Program Slicing & Dataflow Analysis February 2015.
Code Optimization 1 Course Overview PART I: overview material 1Introduction 2Language processors (tombstone diagrams, bootstrapping) 3Architecture of a.
Dataflow Analysis Topic today Data flow analysis: Section 3 of Representation and Analysis Paper (Section 3) NOTE we finished through slide 30 on Friday.
MIT Introduction to Program Analysis and Optimization Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology.
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.
12/5/2002© 2002 Hal Perkins & UW CSER-1 CSE 582 – Compilers Data-flow Analysis Hal Perkins Autumn 2002.
1 Data Flow Analysis Data flow analysis is used to collect information about the flow of data values across basic blocks. Dominator analysis collected.
Problem Reduction So far we have considered search strategies for OR graph. In OR graph, several arcs indicate a variety of ways in which the original.
1 CS 201 Compiler Construction Lecture 2 Control Flow Analysis.
1 Code Optimization Chapter 9 (1 st ed. Ch.10) COP5621 Compiler Construction Copyright Robert van Engelen, Florida State University,
Optimization Simone Campanoni
Code Optimization Data Flow Analysis. Data Flow Analysis (DFA)  General framework  Can be used for various optimization goals  Some terms  Basic block.
Optimal Code Generation (for Expressions) and Data-Flow Analysis Pat Morin COMP 3002.
Data Flow Analysis Suman Jana
Lecture 5 Partial Redundancy Elimination
Iterative Dataflow Problems
CSC D70: Compiler Optimization LICM: Loop Invariant Code Motion
Topic 10: Dataflow Analysis
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.
Advanced Compiler Techniques
Data Flow Analysis Compiler Design
Topic-4a Dataflow Analysis 2019/2/22 \course\cpeg421-08s\Topic4-a.ppt.
Dataflow Analysis Hal Perkins Winter 2008
Static Single Assignment
Live variables and copy propagation
Live Variables – Basic Block
Presentation transcript:

Jeffrey D. Ullman Stanford University

2  Generalizes: 1.Moving loop-invariant computations outside the loop. 2.Eliminating common subexpressions. 3.True partial redundancy: an expression is available along some paths to a point, but not along others.

3  Throughout, assume that neither argument of an expression x+y is modified unless we explicitly assign to x or y.  And of course, we assume x+y is the only expression anyone would ever want to compute.

4 t = x+y a = x+y a = t

5 a = x+yb = x+y c = x+y t = x+y a = t t = x+y b = t c = t

6 a = x+y b = x+y t = x+y a = t t = x+y b = t

7  We could: 1.Add a new block along an edge.  Only necessary if the edge enters a block with several predecessors. 2.Duplicate blocks so an expression x+y is evaluated only along paths where it is needed.

8 t = x+y = t = x+y t = x+y

9  Can exponentiate the number of nodes.  Our PRE algorithm needs to move code to new blocks along edges, but will not split blocks.  Convention: All new instructions are either inserted at the beginning of a block or placed in a new block.

10 1. Determine for each expression the earliest place(s) it can be computed while still being sure that it will be used. 2. Postpone the expressions as long as possible without introducing redundancy.  Trade space for time – an expression can be computed in many places, but never if it is already computed.  Guarantee: No expression is computed where its value might have been computed previously.

3. Determine those places where it is really necessary to store x+y in a temporary rather than compute it when needed.  Example: If x+y is computed in only one place, then we do not want to compute it early and store it. 11

12  We use four data-flow analyses, in succession, plus some set operations on the results of these analyses.  After the first, each analysis uses the results of the previous ones in a role similar to that of Gen (for RD’s) or Use (for LV’s).

13  Expression x+y is anticipated at a point if x+y is certain to be evaluated along any computation path, before any recomputation of x or y.  An example of the fourth kind of DF schema: backwards-intersection.

14 = x+y x+y is anticipated here and could be computed now rather than later. = x+y x+y is anticipated here, but is also available. No computa- tion is needed.

15  Use(B) = set of expressions x+y evaluated in B before any assignment to x or y.  Def(B) = set of expressions one of whose arguments is assigned in B.  Direction = backwards.  Meet = intersection.  Boundary condition: IN[exit] = ∅.  Transfer function: IN[B] = (OUT[B] – Def(B)) ∪ Use(B)

16 = x+y Anticipated Backwards; Intersection; IN[B] = (OUT[B] – Def(B)) ∪ Use(B)

17  Modification of the usual AE.  x+y is “available” at a point if either: 1.It is available in the usual sense; i.e., it has been computed and not killed, or 2.It is anticipated; i.e., it could be available if we chose to precompute it there.

18  x+y is in Kill(B) if x or y is defined, and x+y is not recomputed later in B (same as for earlier definition of “available expressions”).  Direction = Forward  Meet = intersection.  Transfer function: OUT[B] = (IN[B] ∪ IN ANTICIPATED [B]) – Kill(B)

19  x+y is in Earliest[B] if it is anticipated at the beginning of B but not “available” there.  That is: when we compute anticipated expressions, x+y is in IN[B], but  When we compute “available” expressions, x+y is not in IN[B].  I.e., x+y is anticipated at B, but not anticipated at OUT of some predecessor.

20 = x+y Anticipated “Available” Earliest = anticipated but not available Forward; Intersection; OUT[B] = (IN[B] ∪ IN ANTICIPATED [B]) – Kill(B)

21  Now, we need to delay the evaluation of expressions as long as possible, but … 1.Not past the use of the expression. 2.Not so far that we wind up computing an expression that is already evaluated.  Note viewpoint: It is OK to use code space if we save register use.

22  x+y is postponable to a point p if on every path from the entry to p: 1.There is a block B for which x+y is in earliest[B], and 2.After that block, there is no use of x+y.

23  Computed like “available” expressions, with two differences: 1.In place of killing an expression (assigning to one of its arguments): Use(B), the set of expressions used in block B. 2.In place of IN ANTICIPATED [B]: earliest[B].

24  Direction = forward.  Meet = intersection.  Transfer function: OUT[B] = (IN[B] ∪ earliest[B]) – Use(B)

25 = x+y Earliest Postponable Three places to compute x+y Forward; Intersection; OUT[B] = (IN[B] ∪ earliest[B]) – Use(B)

26  We want to postpone as far as possible.  Question: Why?  How do we compute the “winners” – the blocks such that we can postpone no further?  Remember – postponing stops at a use or at a block with another predecessor where x+y is not postponable.

27  For x+y to be in latest[B]: 1.x+y is either in earliest[B] or in IN POSTPONABLE [B].  I.e., we can place the computation at B. 2.x+y is either used in B or there is some successor of B for which (1) does not hold.  I.e., we cannot postpone further along all branches.

28 = x+y Earliest Or Postponable to beginning Used Or has a suc- cessor not red. Latest = gold and red.

29  We’re now ready to introduce a temporary t to hold the value of expression x+y everywhere.  But there is a small glitch: t may be totally unnecessary.  E.g., x+y is computed in exactly one place.

30  used[B] = expressions used along some path from the end of B.  Direction = backward.  Meet = union.  Transfer function: IN[B] = (OUT[B] ∪ e-used[B]) – Latest(B)  e-used = “expression is used in B.”

31 = x+y Recall: Latest Used Backwards; Union; IN[B] = (OUT[B] ∪ e-used[B]) – Latest(B)

32 1. If x+y is in both Latest[B] and OUT USED [B], introduce t = x+y at the beginning of B. 2. If x+y is used in B, but either 1.Is not in Latest[B] or 2.Is in OUT USED [B], replace the use(s) of x+y by uses of t.

33 = x+y Recall: Latest Recall OUT USED Create temp- orary here Use it here But not here --- x+y is in Latest and not in OUT USED

34 = x+y t = x+y = t t = x+y