Lazy Code Motion. Comp 512 Spring 2011

Similar documents
PROGRAM CONTROL FLOW CONTROL FLOW ANALYSIS. Control flow. Control flow analysis. Sequence of operations Representations

An Implementation of Lazy Code Motion for Machine SUIF

A Variation of Knoop, ROthing, and Steffen's Lazy Code Motion

Code Placement, Code Motion

E-path PRE Partial Redundancy Elimination Made Easy

CSC D70: Compiler Optimization LICM: Loop Invariant Code Motion

Partial Redundancy Analysis

Combining Optimizations: Sparse Conditional Constant Propagation

Local Optimization: Value Numbering The Desert Island Optimization. Comp 412 COMP 412 FALL Chapter 8 in EaC2e. target code

Instruction Scheduling Beyond Basic Blocks Extended Basic Blocks, Superblock Cloning, & Traces, with a quick introduction to Dominators.

Introduction to Optimization Local Value Numbering

Register Allocation. Note by Baris Aktemur: Our slides are adapted from Cooper and Torczon s slides that they prepared for COMP 412 at Rice.

Introduction to Optimization. CS434 Compiler Construction Joel Jones Department of Computer Science University of Alabama

Partial Redundancy Elimination and SSA Form

Lecture 10: Lazy Code Motion

The Software Stack: From Assembly Language to Machine Code

Instruction Selection: Preliminaries. Comp 412

Global Register Allocation via Graph Coloring

Loop Invariant Code Mo0on

Lecture 9: Loop Invariant Computation and Code Motion

Partial Redundancy Elimination using Lazy Code Motion

A Fresh Look at PRE as a Maximum Flow Problem

Just-In-Time Compilers & Runtime Optimizers

Lecture 5. Partial Redundancy Elimination

Syntax Analysis, III Comp 412

Example. Example. Constant Propagation in SSA

Syntax Analysis, III Comp 412

Transla'on Out of SSA Form

Parsing II Top-down parsing. Comp 412

Intermediate Representations

Lazy Code Motion. Jens Knoop FernUniversität Hagen. Oliver Rüthing University of Dortmund. Bernhard Steffen University of Dortmund

Data Flow Information. already computed

A Fresh Look at PRE as a Maximum Flow Problem

Handling Assignment Comp 412

Runtime Support for Algol-Like Languages Comp 412

Building a Parser Part III

Code Shape Comp 412 COMP 412 FALL Chapters 4, 5, 6 & 7 in EaC2e. source code. IR IR target. code. Front End Optimizer Back End

Overview Of Op*miza*on, 2

Computing Inside The Parser Syntax-Directed Translation. Comp 412 COMP 412 FALL Chapter 4 in EaC2e. source code. IR IR target.

Data-flow Analysis. Y.N. Srikant. Department of Computer Science and Automation Indian Institute of Science Bangalore

Operator Strength Reduc1on

Intermediate Representations

Parsing. Note by Baris Aktemur: Our slides are adapted from Cooper and Torczon s slides that they prepared for COMP 412 at Rice.

Implementing Control Flow Constructs Comp 412

Lexical Analysis. Note by Baris Aktemur: Our slides are adapted from Cooper and Torczon s slides that they prepared for COMP 412 at Rice.

CS 406/534 Compiler Construction Putting It All Together

Lab 3, Tutorial 1 Comp 412

Runtime Support for OOLs Object Records, Code Vectors, Inheritance Comp 412

CS415 Compilers Register Allocation. These slides are based on slides copyrighted by Keith Cooper, Ken Kennedy & Linda Torczon at Rice University

Procedure and Function Calls, Part II. Comp 412 COMP 412 FALL Chapter 6 in EaC2e. target code. source code Front End Optimizer Back End

Calvin Lin The University of Texas at Austin

Syntax Analysis, V Bottom-up Parsing & The Magic of Handles Comp 412

CS415 Compilers. Instruction Scheduling and Lexical Analysis

Generating Code for Assignment Statements back to work. Comp 412 COMP 412 FALL Chapters 4, 6 & 7 in EaC2e. source code. IR IR target.

Computing Inside The Parser Syntax-Directed Translation, II. Comp 412

Computing Inside The Parser Syntax-Directed Translation, II. Comp 412 COMP 412 FALL Chapter 4 in EaC2e. source code. IR IR target.

Middle End. Code Improvement (or Optimization) Analyzes IR and rewrites (or transforms) IR Primary goal is to reduce running time of the compiled code

Local Register Allocation (critical content for Lab 2) Comp 412

More Dataflow Analysis

Introduction to Parsing. Comp 412

Memory Redundancy Elimination to Improve Application Energy Efficiency

Compiler Design. Fall Data-Flow Analysis. Sample Exercises and Solutions. Prof. Pedro C. Diniz

Computing Inside The Parser Syntax-Directed Translation. Comp 412

Parsing III. CS434 Lecture 8 Spring 2005 Department of Computer Science University of Alabama Joel Jones

Data Flow Analysis. Daqing Hou

Arrays and Functions

Data Flow Analysis. CSCE Lecture 9-02/15/2018

Compiler Optimisation

Copyright 2003, Keith D. Cooper, Ken Kennedy & Linda Torczon, all rights reserved. Students enrolled in Comp 412 at Rice University have explicit

Why Data Flow Models? Dependence and Data Flow Models. Learning objectives. Def-Use Pairs (1) Models from Chapter 5 emphasized control

Data-flow Analysis - Part 2

Naming in OOLs and Storage Layout Comp 412

Dependence and Data Flow Models. (c) 2007 Mauro Pezzè & Michal Young Ch 6, slide 1

The Processor Memory Hierarchy

Syntax Analysis, VII One more LR(1) example, plus some more stuff. Comp 412 COMP 412 FALL Chapter 3 in EaC2e. target code.

Introduction to Optimization, Instruction Selection and Scheduling, and Register Allocation

Loop Optimizations. Outline. Loop Invariant Code Motion. Induction Variables. Loop Invariant Code Motion. Loop Invariant Code Motion

Optimizer. Defining and preserving the meaning of the program

Compiler Optimization and Code Generation

Lexical Analysis - An Introduction. Lecture 4 Spring 2005 Department of Computer Science University of Alabama Joel Jones

ELEC 876: Software Reengineering

Grammars. CS434 Lecture 15 Spring 2005 Department of Computer Science University of Alabama Joel Jones

Code Merge. Flow Analysis. bookkeeping

Syntax Analysis, VI Examples from LR Parsing. Comp 412

Data Structures and Algorithms in Compiler Optimization. Comp314 Lecture Dave Peixotto

Lecture 3 Local Optimizations, Intro to SSA

Anticipation-based partial redundancy elimination for static single assignment form

Code Shape II Expressions & Assignment

The So'ware Stack: From Assembly Language to Machine Code

Parsing II Top-down parsing. Comp 412

Languages and Compiler Design II IR Code Optimization

CS 406/534 Compiler Construction Instruction Scheduling

Optimal Code Motion: Theory and Practice

Instruction Selection, II Tree-pattern matching

Global Register Allocation via Graph Coloring The Chaitin-Briggs Algorithm. Comp 412

The ILOC Virtual Machine (Lab 1 Background Material) Comp 412

Data Flow Analysis. Program Analysis

Compiler Design. Fall Control-Flow Analysis. Prof. Pedro C. Diniz

Advanced Compiler Construction

Sustainable Memory Use Allocation & (Implicit) Deallocation (mostly in Java)

Transcription:

Comp 512 Spring 2011 Lazy Code Motion Lazy Code Motion, J. Knoop, O. Ruthing, & B. Steffen, in Proceedings of the ACM SIGPLAN 92 Conference on Programming Language Design and Implementation, June 1992. A Variation of Knoop, Ruthing, and Steffen s Lazy Code Motion, K. Drechsler & M. Stadel, SIGPLAN Notices, 28(5), May 1993 10.3.1 of EaC2e Copyright 2011, Keith D. Cooper & Linda Torczon, all rights reserved. Students enrolled in Comp 512 at Rice University have explicit permission to make copies of these materials for their personal use. Faculty from other educational institutions may use these materials for nonprofit educational purposes, provided this copyright notice is preserved. COMP 512, Rice University! Drechsler & Stadel give a much more complete and satisfying example. 1!

Redundant Expression An expression is redundant at point p if, on every path to p 1. It is evaluated before reaching p, and 2. Non of its constitutent values is redefined before p Example Some occurrences of b+c are redundant b! b + 1 COMP 512, Rice University! * 2!

Partially Redundant Expression An expression is partially redundant at p if it is redundant along some, but not all, paths reaching p Example b! b + 1 b! b + 1 Inserting a copy of after the definition of b can make it redundant fully redundant? COMP 512, Rice University! * 3!

Loop Invariant Expression Another example x! y * z a! b * c b+c is partially redundant here x! y * z a! b * c a! b * c Loop invariant expressions are partially redundant Partial redundancy elimination performs code motion Major part of the work is figuring out where to insert operations COMP 512, Rice University! 4!

The concept Solve data-flow problems that show opportunities & limits > Availability & anticipability Compute INSERT & DELETE sets from solutions Linear pass over the code to rewrite it (using INSERT & DELETE) The history Partial redundancy elimination (Morel & Renvoise, CACM, 1979) Improvements by Drechsler & Stadel, Joshi & Dhamdhere, Chow, Knoop, Ruthing & Steffen, Dhamdhere, Sorkin, All versions of PRE optimize placement > Guarantee that no path is lengthened LCM was invented by Knoop et al. in PLDI, 1992 Drechsler & Stadel simplified the equations PRE and its descendants are conservative COMP 512, Rice University! Citations for the critical papers are on the title page. 5!

The intuitions Compute available expressions Compute anticipable expressions LCM operates on expressions It moves expression evaluations, not assignments From AVAIL & ANT, we can compute an earliest placement for each expression Push expressions down the CFG until it changes behavior Assumptions Uses a lexical notion of identity (not value identity) ILOC-style code with unlimited name space Consistent, disciplined use of names > Identical expressions define the same name > No other expression defines that name }Avoids copies Result serves as proxy COMP 512, Rice University! 6!

Digression in Chapter 5 of EAC: The impact of naming The Name Space r i + r j "r k, always, with both i < k and j < k (hash to find k) We can refer to r i + r j by r k (bit-vector sets) Variables must be set by copies > No consistent definition for a variable > Break the rule for this case, but require r source > r destination > To achieve this, assign register names to variables first Without this name space LCM must insert copies to preserve redundant values LCM must compute its own map of expressions to unique ids LCM operates on expressions COMP 512, Rice University! It moves expression evaluations, not assignments 7!

Local Informtion (Computed for each block) DEEXPR(b) contains expressions defined in b that survive to the end of b (downward exposed expressions) e # DEEXPR(b) $ evaluating e at the end of b produces the same value for e UEEXPR(b) contains expressions defined in b that have upward exposed arguments (both args) (upward exposed expressions) e # UEEXPR(b) $ evaluating e at the start of b produces the same value for e EXPRKILL(b) contains those expressions that have one or more arguments defined (killed ) in b (killed expressions) e % EXPRKILL(b) $ evaluating e produces the same result at the start and end of b COMP 512, Rice University! 8!

Availability AVAILIN(n) = ' m! preds(n) AVAILOUT(m), n! n 0 AVAILOUT(m) = DEEXPR(m) ( (AVAILIN(m) ' EXPRKILL(m)) Initialize AVAILIN(n) to the set of all names, except at n 0 Set AVAILIN(n 0 ) to Ø Interpreting AVAIL e # AVAILOUT(b) & evaluating e at end of b produces the same value for e. AVAILOUT tells the compiler that an evaluation at the end of the block is covered by the evaluation earlier in the block. It also shows that evaluation of e can move to the end of the block. This interpretation differs from the way we talk about AVAIL in global redundancy elimination; the equations, however, are unchanged. COMP 512, Rice University! 9!

Anticipability is identical to VeryBusy expressions Anticipability ANTOUT(n) = ' m! succs(n) ANTIN(m), n not an exit block ANTIN(m) = UEEXPR (m) ( (ANTOUT(m) ' EXPRKILL(m)) Initialize ANTOUT(n) to the set of all names, except at exit blocks Set ANTOUT(n) to Ø, for each exit block n Interpreting ANTOUT e # ANTIN(b) & evaluating e at start of b produces the same value for e. ANTIN tells the compiler how far backward e can move. If e is also in AVAILIN(b), the evaluation in the block is redundant. This view shows that anticipability is, in some sense, the inverse of availablilty (& explains the new interpretation of AVAIL) COMP 512, Rice University! 10!

The intuitions Available expressions e # AVAILOUT(b ) $ evaluating e at exit of b gives same result $ e could move to exit of b e # AVAILIn(b ) $ e is available from every predecessor of b $ an evaluation of e at entry of b is redundant Anticipable expressions e # ANTIN(b ) $ evaluating e at entry of b gives same result $ e could move to entry of b e # ANTOUT(b ) $ e is used on every path leaving b $ evaluations in b s successors could move to the end of b COMP 512, Rice University! 11!

Earliest placement on an edge EARLIEST(i,j) = ANTIN(j) ' AVAILOUT(i) ' (EXPRKILL(i) ( ANTOUT(i)) EARLIEST(n 0,j) = ANTIN(j) ' AVAILOUT(n 0 ) Can move e to head of j & it is not redundant from i and Either killed in i or would not be busy at exit of i $ insert e on the edge EARLIEST is a predicate Computed for edges rather than nodes (placement ) e # EARLIEST(i,j) if > It can move to head of j, (ANTIN(j)) > It is not available at the end of i and (EXPRKILL(i)) > either it cannot move to the head of i or another edge leaving i prevents its placement in i (ANTOUT(i)) COMP 512, Rice University! 12!

Later (than earliest) placement LATERIN(j) = ' i! pred(j) LATER(i,j), j! n 0 LATER(i,j) = EARLIEST(i,j) ( (LATERIN(i) ' UEEXPR(i)) Initialize LATERIN(n 0 ) to Ø x # LATERIN(k) & every path that reaches k has x # EARLIEST(i,j) for some edge (i,j) leading to x, and the path from the entry of j to k is x-clear & does not evaluate x $ the compiler can move x through k without losing any benefit x # LATER(i,j) & <i,j> is its earliest placement, or it can be moved forward from i (LATER(i)) and placement at entry to i does not anticipate a use in i (moving it across the edge exposes that use) COMP 512, Rice University! Propagate forward until a block kills it (UEEXPR) 13!

Rewriting the code INSERT(i,j) = LATER(i,j) ' LATERIN(j) Can go on the edge but not in j $ no later placement DELETE(k) = UEEXPR(k) ' LATERIN(k), k! n 0 Upward exposed (so we will cover it) & not an evaluation that might be used later INSERT & DELETE are predicates Compiler uses them to guide the rewrite step x # INSERT(i,j) $ insert x at start of j, end of i, or new block x # DELETE(k) $ delete first evaluation of x in k If local redundancy elimination has already been performed, only one copy of x exists. Otherwise, COMP 512, Rice University! * 14! remove all upward exposed copies of x

Edge placement x # INSERT(i,j) x B i B i x B h B i B j x B j B k B j B k succs(i) = 1 preds(j) = 1 succs(i) > 1 & preds(j) > 1 A critical edge Three cases succs(i) = 1 $ insert at end of i succs(i) > 1, but preds(j) = 1$ insert at start of j succs(i) > 1, & preds(j) > 1 $ create new block in <i,j> for x COMP 512, Rice University! 15!

Example from Knoop et al. 1 2 a! c Original Code 3 x! a + b 4 5 6 7 8 9 10 y! a + b 11 12 13 14 15 y! a + b 16 z! a + b 17 x! a + b COMP 512, Rice University! 18 Assume that bad things can happen in an empty box 16!

Example from Knoop et al. 1 2 a! c After LCM 3 x! a + b 4 5 6 7 8 h! a + b 9 10 y! h 11 12 13 14 15 h! a + b y! h 16 z! h 17 x! a + b COMP 512, Rice University! 18 17!

Example B 1 : r 1! 1 r 2! r 0 + @m if r 1 < r 2 " B 2,B 3 B 2 : r 20! r 17 * r 18... r 4! r 1 + 1 r 1! r 4 if r 1 < r 2 " B 2,B 3 B 3 :... B 1 B 2 B 3 Critical edge rule will create landing pad when needed, as on edge (B 1,B 2 ) Example is too small to show off Later Insert(1,2) = { r 20 } Delete(2) = { r 20 } COMP 512, Rice University! 18!