CS 536 Spring 20011 Intermediate Code. Local Optimizations. Lecture 22.

Slides:



Advertisements
Similar presentations
Example of Constructing the DAG (1)t 1 := 4 * iStep (1):create node 4 and i 0 Step (2):create node Step (3):attach identifier t 1 (2)t 2 := a[t 1 ]Step.
Advertisements

Synopsys University Courseware Copyright © 2012 Synopsys, Inc. All rights reserved. Compiler Optimization and Code Generation Lecture - 3 Developed By:
P3 / 2004 Register Allocation. Kostis Sagonas 2 Spring 2004 Outline What is register allocation Webs Interference Graphs Graph coloring Spilling Live-Range.
7. Optimization Prof. O. Nierstrasz Lecture notes by Marcus Denker.
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.
CMPUT Compiler Design and Optimization1 CMPUT680 - Winter 2006 Topic 5: Peep Hole Optimization José Nelson Amaral
Compilation 2011 Static Analysis Johnni Winther Michael I. Schwartzbach Aarhus University.
ECE 454 Computer Systems Programming Compiler and Optimization (I) Ding Yuan ECE Dept., University of Toronto
1 CS 201 Compiler Construction Machine Code Generation.
Control-Flow Graphs & Dataflow Analysis CS153: Compilers Greg Morrisett.
Chapter 10 Code Optimization. A main goal is to achieve a better performance Front End Code Gen Intermediate Code source Code target Code user Machine-
1 Code Optimization Code produced by compilation algorithms can often be improved (ideally optimized) in terms of run-time speed and the amount of memory.
1 Compiler Construction Intermediate Code Generation.
Program Representations. Representing programs Goals.
From AST to Code Generation Professor Yihjia Tsai Tamkang University.
CS412/413 Introduction to Compilers Radu Rugina Lecture 16: Efficient Translation to Low IR 25 Feb 02.
Representing programs Goals. Representing programs Primary goals –analysis is easy and effective just a few cases to handle directly link related things.
CS 536 Spring Global Optimizations Lecture 23.
Peephole Optimization Final pass over generated code: examine a few consecutive instructions: 2 to 4 See if an obvious replacement is possible: store/load.
Improving code generation. Better code generation requires greater context Over expressions: optimal ordering of subtrees Over basic blocks: Common subexpression.
1 Intermediate representation Goals: –encode knowledge about the program –facilitate analysis –facilitate retargeting –facilitate optimization scanning.
4/23/09Prof. Hilfinger CS 164 Lecture 261 IL for Arrays & Local Optimizations Lecture 26 (Adapted from notes by R. Bodik and G. Necula)
CS 536 Spring Code generation I Lecture 20.
Prof. Bodik CS 164 Lecture 171 Register Allocation Lecture 19.
4/25/08Prof. Hilfinger CS164 Lecture 371 Global Optimization Lecture 37 (From notes by R. Bodik & G. Necula)
Code Generation for Basic Blocks Introduction Mooly Sagiv html:// Chapter
4/18/08Prof. Hilfinger CS 164 Lecture 341 Other Forms of Intermediate Code. Local Optimizations Lecture 34 (Adapted from notes by R. Bodik and G. Necula)
Register Allocation (via graph coloring)
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.
Register Allocation (via graph coloring). Lecture Outline Memory Hierarchy Management Register Allocation –Register interference graph –Graph coloring.
Prof. Fateman CS 164 Lecture 221 Global Optimization Lecture 22.
Intermediate Code. Local Optimizations
1 Liveness analysis and Register Allocation Cheng-Chia Chen.
Improving Code Generation Honors Compilers April 16 th 2002.
Prof. Fateman CS164 Lecture 211 Local Optimizations Lecture 21.
Improving code generation. Better code generation requires greater context Over expressions: optimal ordering of subtrees Over basic blocks: Common subexpression.
Compiler Construction A Compulsory Module for Students in Computer Science Department Faculty of IT / Al – Al Bayt University Second Semester 2008/2009.
Machine-Independent Optimizations Ⅰ CS308 Compiler Theory1.
4/29/09Prof. Hilfinger CS164 Lecture 381 Register Allocation Lecture 28 (from notes by G. Necula and R. Bodik)
Prof. Bodik CS 164 Lecture 16, Fall Global Optimization Lecture 16.
Topic #10: Optimization EE 456 – Compiling Techniques Prof. Carl Sable Fall 2003.
Introduction For some compiler, the intermediate code is a pseudo code of a virtual machine. Interpreter of the virtual machine is invoked to execute the.
What’s in an optimizing compiler?
COP 4620 / 5625 Programming Language Translation / Compiler Writing Fall 2003 Lecture 10, 10/30/2003 Prof. Roy Levow.
1 Code Generation Part II Chapter 8 (1 st ed. Ch.9) COP5621 Compiler Construction Copyright Robert van Engelen, Florida State University,
U NIVERSITY OF D ELAWARE C OMPUTER & I NFORMATION S CIENCES D EPARTMENT Optimizing Compilers CISC 673 Spring 2009 Register Allocation John Cavazos University.
CSc 453 Final Code Generation Saumya Debray The University of Arizona Tucson.
1 Code Generation Part II Chapter 9 COP5621 Compiler Construction Copyright Robert van Engelen, Florida State University, 2005.
1 Code optimization “Code optimization refers to the techniques used by the compiler to improve the execution efficiency of the generated object code”
Compiler Principles Fall Compiler Principles Lecture 0: Local Optimizations Roman Manevich Ben-Gurion University.
Synopsys University Courseware Copyright © 2012 Synopsys, Inc. All rights reserved. Compiler Optimization and Code Generation Lecture - 1 Developed By:
Cleaning up the CFG Eliminating useless nodes & edges C OMP 512 Rice University Houston, Texas Fall 2003 Copyright 2003, Keith D. Cooper & Linda Torczon,
CS412/413 Introduction to Compilers Radu Rugina Lecture 18: Control Flow Graphs 29 Feb 02.
CS412/413 Introduction to Compilers and Translators April 2, 1999 Lecture 24: Introduction to Optimization.
CS 404Ahmed Ezzat 1 CS 404 Introduction to Compiler Design Lecture 10 Ahmed Ezzat.
©SoftMoore ConsultingSlide 1 Code Optimization. ©SoftMoore ConsultingSlide 2 Code Optimization Code generation techniques and transformations that result.
More Code Generation and Optimization Pat Morin COMP 3002.
Code Optimization Code produced by compilation algorithms can often be improved (ideally optimized) in terms of run-time speed and the amount of memory.
Code Optimization Overview and Examples
High-level optimization Jakub Yaghob
Code Optimization.
Compilers Principles, Techniques, & Tools Taught by Jing Zhang
Optimization Code Optimization ©SoftMoore Consulting.
Code Optimization Overview and Examples Control Flow Graph
Data Flow Analysis Compiler Design
Optimization 薛智文 (textbook ch# 9) 薛智文 96 Spring.
Intermediate Code Generation
Code Generation Part II
Code Optimization.
Presentation transcript:

CS 536 Spring Intermediate Code. Local Optimizations. Lecture 22

CS 536 Spring Lecture Outline Intermediate code Local optimizations Next time: global optimizations

CS 536 Spring Code Generation Summary We have discussed –Runtime organization –Simple stack machine code generation –Improvements to stack machine code generation Our compiler goes directly from AST to assembly language –And does not perform optimizations Most real compilers use intermediate languages

CS 536 Spring Why Intermediate Languages ? When to perform optimizations –On AST Pro: Machine independent Con: Too high level –On assembly language Pro: Exposes optimization opportunities Con: Machine dependent Con: Must reimplement optimizations when retargetting –On an intermediate language Pro: Machine independent Pro: Exposes optimization opportunities

CS 536 Spring Intermediate Languages Each compiler uses its own intermediate language –IL design is still an active area of research Intermediate language = high-level assembly language –Uses register names, but has an unlimited number –Uses control structures like assembly language –Uses opcodes but some are higher level E.g., push translates to several assembly instructions Most opcodes correspond directly to assembly opcodes

CS 536 Spring Three-Address Intermediate Code Each instruction is of the form x := y op z –y and z can be only registers or constants –Just like assembly Common form of intermediate code The AST expression x + y * z is translated as t 1 := y * z t 2 := x + t 1 –Each subexpression has a “home”

CS 536 Spring Generating Intermediate Code Similar to assembly code generation Major difference –Use any number of IL registers to hold intermediate results

CS 536 Spring Generating Intermediate Code (Cont.) Igen(e, t) function generates code to compute the value of e in register t Example: igen(e 1 + e 2, t) = igen(e 1, t 1 ) (t 1 is a fresh register) igen(e 2, t 2 ) (t 2 is a fresh register) t := t 1 + t 2 Unlimited number of registers  simple code generation

CS 536 Spring An Intermediate Language P  S P |  S  id := id op id | id := op id | id := id | push id | id := pop | if id relop id goto L | L: | jump L id’s are register names Constants can replace id’s Typical operators: +, -, *

CS 536 Spring Definition. Basic Blocks A basic block is a maximal sequence of instructions with: –no labels (except at the first instruction), and –no jumps (except in the last instruction) Idea: –Cannot jump into a basic block (except at beginning) –Cannot jump out of a basic block (except at end) –Each instruction in a basic block is executed after all the preceding instructions have been executed

CS 536 Spring Basic Block Example Consider the basic block 1.L: 2. t := 2 * x 3. w := t + x 4. if w > 0 goto L’ No way for (3) to be executed without (2) having been executed right before –We know we can change (3) to w := 3 * x –Can we eliminate (2) as well?

CS 536 Spring Definition. Control-Flow Graphs A control-flow graph is a directed graph with –Basic blocks as nodes –An edge from block A to block B if the execution can flow from the last instruction in A to the first instruction in B –E.g., the last instruction in A is jump L B –E.g., the execution can fall-through from block A to block B

CS 536 Spring Control-Flow Graphs. Example. The body of a method (or procedure) can be represented as a control- flow graph There is one initial node All “return” nodes are terminal x := 1 i := 1 L: x := x * x i := i + 1 if i < 10 goto L

CS 536 Spring Optimization Overview Optimization seeks to improve a program’s utilization of some resource –Execution time (most often) –Code size –Network messages sent, etc. Optimization should not alter what the program computes –The answer must still be the same

CS 536 Spring A Classification of Optimizations For languages like C and Java there are three granularities of optimizations 1.Local optimizations Apply to a basic block in isolation 2.Global optimizations Apply to a control-flow graph (method body) in isolation 3.Inter-procedural optimizations Apply across method boundaries Most compilers do (1), many do (2) and very few do (3)

CS 536 Spring Cost of Optimizations In practice, a conscious decision is made not to implement the fanciest optimization known Why? –Some optimizations are hard to implement –Some optimizations are costly in terms of compilation time –The fancy optimizations are both hard and costly The goal: maximum improvement with minimum of cost

CS 536 Spring Local Optimizations The simplest form of optimizations No need to analyze the whole procedure body –Just the basic block in question Example: algebraic simplification

CS 536 Spring Algebraic Simplification Some statements can be deleted x := x + 0 x := x * 1 Some statements can be simplified x := x * 0  x := 0 y := y ** 2  y := y * y x := x * 8  x := x << 3 x := x * 15  t := x << 4; x := t - x (on some machines << is faster than *; but not on all!)

CS 536 Spring Constant Folding Operations on constants can be computed at compile time In general, if there is a statement x := y op z –And y and z are constants –Then y op z can be computed at compile time Example: x :=  x := 4 Example: if 2 < 0 jump L can be deleted When might constant folding be dangerous?

CS 536 Spring Flow of Control Optimizations Eliminating unreachable code: –Code that is unreachable in the control-flow graph –Basic blocks that are not the target of any jump or “fall through” from a conditional –Such basic blocks can be eliminated Why would such basic blocks occur? Removing unreachable code makes the program smaller –And sometimes also faster Due to memory cache effects (increased spatial locality)

CS 536 Spring Single Assignment Form Some optimizations are simplified if each register occurs only once on the left-hand side of an assignment Intermediate code can be rewritten to be in single assignment form x := z + y b := z + y a := x  a := b x := 2 * x x := 2 * b (b is a fresh register) –More complicated in general, due to loops

CS 536 Spring Common Subexpression Elimination Assume –Basic block is in single assignment form –A definition x := is the first use of x in a block If any assignment have the same rhs, they compute the same value Example: x := y + z …  … w := y + z w := x (the values of x, y, and z do not change in the … code)

CS 536 Spring Copy Propagation If w := x appears in a block, all subsequent uses of w can be replaced with uses of x Example: b := z + y b := z + y a := b  a := b x := 2 * a x := 2 * b This does not make the program smaller or faster but might enable other optimizations –Constant folding –Dead code elimination

CS 536 Spring Copy Propagation and Constant Folding Example: a := 5 x := 2 * a  x := 10 y := x + 6 y := 16 t := x * y t := x << 4

CS 536 Spring Copy Propagation and Dead Code Elimination If w := rhs appears in a basic block w does not appear anywhere else in the program Then the statement w := rhs is dead and can be eliminated –Dead = does not contribute to the program’s result Example: (a is not used anywhere else) x := z + y b := z + y b := x + y a := x  a := b  x := 2 * b x := 2 * x x := 2 * b

CS 536 Spring Applying Local Optimizations Each local optimization does very little by itself Typically optimizations interact –Performing one optimizations enables other opt. Typical optimizing compilers repeatedly perform optimizations until no improvement is possible –The optimizer can also be stopped at any time to limit the compilation time

CS 536 Spring An Example Initial code: a := x ** 2 b := 3 c := x d := c * c e := b * 2 f := a + d g := e * f

CS 536 Spring An Example Algebraic optimization: a := x ** 2 b := 3 c := x d := c * c e := b * 2 f := a + d g := e * f

CS 536 Spring An Example Algebraic optimization: a := x * x b := 3 c := x d := c * c e := b << 1 f := a + d g := e * f

CS 536 Spring An Example Copy propagation: a := x * x b := 3 c := x d := c * c e := b << 1 f := a + d g := e * f

CS 536 Spring An Example Copy propagation: a := x * x b := 3 c := x d := x * x e := 3 << 1 f := a + d g := e * f

CS 536 Spring An Example Constant folding: a := x * x b := 3 c := x d := x * x e := 3 << 1 f := a + d g := e * f

CS 536 Spring An Example Constant folding: a := x * x b := 3 c := x d := x * x e := 6 f := a + d g := e * f

CS 536 Spring An Example Common subexpression elimination: a := x * x b := 3 c := x d := x * x e := 6 f := a + d g := e * f

CS 536 Spring An Example Common subexpression elimination: a := x * x b := 3 c := x d := a e := 6 f := a + d g := e * f

CS 536 Spring An Example Copy propagation: a := x * x b := 3 c := x d := a e := 6 f := a + d g := e * f

CS 536 Spring An Example Copy propagation: a := x * x b := 3 c := x d := a e := 6 f := a + a g := 6 * f

CS 536 Spring An Example Dead code elimination: a := x * x b := 3 c := x d := a e := 6 f := a + a g := 6 * f Note: assume b, c, d, e are temporaries (introduced by the compiler) and hence are not used outside this basic block

CS 536 Spring An Example Dead code elimination: a := x * x f := a + a g := 6 * f This is the final form

CS 536 Spring Peephole Optimizations on Assembly Code The optimizations presented before work on intermediate code –They are target independent –But they can be applied on assembly language also Peephole optimization is an effective technique for improving assembly code –The “peephole” is a short sequence of (usually contiguous) instructions –The optimizer replaces the sequence with another equivalent one (but faster)

CS 536 Spring Peephole Optimizations (Cont.) Write peephole optimizations as replacement rules i 1, …, i n  j 1, …, j m where the rhs is the improved version of the lhs Example: move $a $b, move $b $a  move $a $b –Works if move $b $a is not the target of a jump Another example addiu $a $a i, addiu $a $a j  addiu $a $a i+j

CS 536 Spring Peephole Optimizations (Cont.) Many (but not all) of the basic block optimizations can be cast as peephole optimizations –Example: addiu $a $b 0  move $a $b –Example: move $a $a  –These two together eliminate addiu $a $a 0 Just like for local optimizations, peephole optimizations need to be applied repeatedly to get maximum effect

CS 536 Spring Local Optimizations. Notes. Intermediate code is helpful for many optimizations Many simple optimizations can still be applied on assembly language “Program optimization” is grossly misnamed –Code produced by “optimizers” is not optimal in any reasonable sense –“Program improvement” is a more appropriate term Next time: global optimizations