DOCSLIB.ORG

Topic-IC Dataflow Analysis

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Topic-IC Dataflow Analysis Topic-I-C Dataflow Analysis 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 1 Global Dataflow Analysis Motivation We need to know variable def and use information between basic blocks for: • constant folding • dead-code elimination • redundant computation elimination • code motion • induction variable elimination • build data dependence graph (DDG) • etc. 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 2 Topics of DataFlow Analysis • Reaching definition • Live variable analysis • ud-chains and du-chains • Available expressions • Others .. 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 3 Definition and Use 1. Definition & Use 푆: 푣1 = … 푣2 푆 is a “definition” of 푣1 푆 is a “use” of 푣2 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 4 Compute Def and Use Information of a Program P? Case 1: P is a basic block ? Case 2: P contains more than one basic blocks ? 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 5 Points and Paths B1 points in a basic block: d1: i := m-1 - between statements d : j := n 2 - before the first statement d3: a := u1 - after the last statement B2 d4: i := i+1 B3 d5: j := j+1 In the example, how many points basic block B1, B2, B3, and B5 have? B4 B5 B6 B1 has four, B2, B3, and B5 d : a := u2 6 have two points each. 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 6 Points and Paths B1 d1: i := m-1 A path is a sequence of points d : j := n 2 p1, p2, …, pn such that either: d3: a := u1 (i) if pi immediately precedes S, B2 than pi+1 immediately follows S. d4: i := i+1 (ii) or pi is the end of a basic block and pi+1 is the beginning of a successor block B3 d : j := j+1 5 In the example, is there a path from B4 the beginning of block B5 to the beginning of block B6? B5 B6 Yes, it travels through the end point d : a := u2 6 of B5 and then through all the points in B2, B3, and B4. 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 7 Reach and Kill Kill a definition d1 of a variable v d : x := … 1 is killed between p1 and p2 if in every path from p1 to p2 there is another definition of v. Reach a definition d reaches a point p d2 : x := … if a path d p, and d is not killed along the path In the example, do d1 and d2 reach the both d1, d2 reach point points and ? but only d1 reaches point 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 8 Reach Example S0: PROGRAM S1: READ(L) 1 B1 S2: N = 0 S3: K = 0 S4: M = 1 S5: K = K + M B2 2 S6: C = K > L S7: IF C THEN GOTO S11 S8: N = N + 1 B3 S9: M = M + 2 S10: GOTO S5 3 4 B4 S11: WRITE(N) S12: END The set of defs reaching the use of N in S8: {S2, S8} def S2 reach S11 along statement path: (S2, S3, S4, S5, S6, S7, S11) S8 reach S11 along statement path: (S8, S9, S10, S5, S6, S7, S11) 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 9 Problem Formulation: Example 1 Can d1 reach point p1? d1 x := exp1 d1 x := exp1 s if p > 0 s1 if p > 0 1 s2 x := x + 1 p1 s3 a = b + c s2 x := x + 1 s4 e = x + 1 p1 s3 a = b + c It depends on what point p1 represents!!! s4 e = x + 1 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 10 Problem Formulation: Example 2 d1 x := exp1 Can d1 and d4 reach point p3? s2 if y > 0 d1 x := exp1 s2 while y > 0 do s3 a := b + 2 s3 a := b + 2 p3 p3 d4 x := exp2 d4 x = exp2 s5 c := a + 1 end while s5 c = a + 1 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 11 Data-Flow Analysis of Structured Programs Structured programs have an useful property: there is a single point of entrance and a single exit point for each statement. We will consider program statements that can be described by the following syntax: Statement id := Expression | Statement ; Statement | if Expression then Statement else Statement | do Statement while Expression Expression id + id | id 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 12 Structured Programs S ::= id := E | S ; S This restricted syntax results in the | if E then S else S forms depicted below for flowgraphs | do S while E E ::= id + id | id S1 S1 If E goto S1 S2 S1 S2 If E goto S1 S1 S2 if E then S1 else S2 do S1 while E 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 13 Data-Flow Values 1. Each program point associates with a data-flow value 2. A data-flow value represents the possible program states that can be observed for that program point. 3. The data-flow value depends on the goal of the analysis. Given a statement 푆, 푛(푆) and 표푢푡(푆) denote the data-flow values before and after 푆, respectively. 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 14 Data-Flow Values of Basic Block Assume basic block 푩 consists of statement 풔ퟏ, 풔ퟐ, … , 풔풏 (풔ퟏ is the first statement of 푩 and 풔풏 is the last statement of 푩), the data-flow values immediately before and after 푩 is denoted as: 풊풏 푩 = 풊풏 풔ퟏ 풐풖풕 푩 = 풐풖풕(풔풏) 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 15 Instances of Data-Flow Problems ● Reaching Definitions ● Live-Variable Analysis ● DU Chains and UD Chains ● Available Expressions To solve these problems we must take into consideration the data-flow and the control flow in the program. A common method to solve such problems is to create a set of data- flow equations. 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 16 Iterative Method for Dataflow Analysis Establish a set of dataflow relations for each basic block Establish a set dataflow equations between basic blocks Establish an initial solution Iteratively solve the dataflow equations, until a fixed point is reached. 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 17 Generate set: gen(S) In general, 푑 ∈ 푔푒푛(푆) if 푑 reaches the end of 푆 independent of whether it reaches the beginning of 푆. We restrict 푔푒푛(푆) contains only the definition in 푆. If 푆 is a basic block, gen(푆) contains all the definitions inside the basic block that are “visible” immediately after the block. 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 18 Kill Set: kill(S) 풅 ∈ 푘푙푙 푺 ⇒ 푑 never reaches the end of 푺. This is equivalent to say: reaches end of 풅 푺 풅 ∉ 푘푙푙(푆) d1 a := d2 a := ... dk a : dd a := S dd: a := b + c 푘푙푙(푠) = 퐷푎 − { 푑푑 } Of course the statements d1,d2, …, dk all get killed except dd itself. A basic block’s kill set is simply the union of all the definitions killed by its individual statements! 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 19 Reaching Definitions Problem Statement: Given a program and a program point determine the set of definitions reaching this point in a program. 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 20 Iterative Algorithm for Reaching Definitions dataflow equations The set of definitions reaching the entry of basic block B: 푛(푩) = 표푢푡(푷) 푷 ∈ 푝푟푒푑푒푐푒푠푠표푟(푩) The set of definitions reaching the exit of basic block B: 표푢푡 푩 = 푔푒푛 푩 ∪ { 푛 푩 − kill 퐁 } 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 21 (AhoSethiUllman, pp. 606) Iterative Algorithm for Reaching Definitions Algorithm 1) 풐풖풕(푬푵푻푹풀) = ; 2) for (each basic block 푩 other than 푬푵푻푹풀) 풐풖풕(푩) = ; Need a flag to test if a out 3) while ( changes to any out occur) is changed! The initial value of the flag is true. 4) for ( each 푩 other than 푬푵푻푹풀) { 풊풏 푩 = 푷 ∈풑풓풆풅풆풄풆풔풔풐풓풔 풐풇 푩 풐풖풕(푷) ; 풐풖풕 푩 = 품풆풏 푩 ∪ 풊풏 푩 − 풌풊풍풍 풃 ; } Dataflow Equations – a simple case 푔푒푛 푆 = 푑 Da is the set of all definitions in the S d : a := b + c 푘푙푙 (푆) = 퐷푎 − {푑} program for variable a! S 푔푒푛(푆) = 푔푒푛 (푆2) ∪ (푔푒푛(푆1) − 푘푙푙(푆2)) S 1 S 2 푘푙푙 푆 = 푘푙푙(푆2) ∪ (푘푙푙(푆1) − 푔푒푛(푆2)) 푔푒푛(푆) = 푔푒푛(푆1) ∪ 푔푒푛(푆2) S S1 S2 푘푙푙(푆) = 푘푙푙(푆1) ∩ 푘푙푙(푆2) flow equations for reaching definitions reaching for equations flow - 푔푒푛(푆) = 푔푒푛(푆1) S S1 푘푙푙(푆) = 푘푙푙(푆1) Date 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 23 Dataflow Equations S d : a := b + c 표푢푡(푆) = 푔푒푛(푆) ∪ (푛(푆) − 푘푙푙(푆)) S 푛(푆) = 푛(푆1) S 1 푛(푆2) = 표푢푡(푆1) S2 표푢푡(푆) = 표푢푡(푆2) S S1 S2 푛 푆 = 푛 푆1 = 푛 푆2 표푢푡(푆) = 표푢푡(푆1) ∪ 표푢푡(푆2) flow equations for reaching definitions reaching for equations flow - 푛(푆) = 푛(푆 ) ∪ 표푢푡(푆 ) S S1 1 1 Date 표푢푡(푆) = 표푢푡(푆1) 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 24 Dataflow Analysis: An Example Using RD (reaching def) as an example: d1 : i = 0 Question: in What is the set of reaching loop L . definitions at the exit of the loop L? . d2 : i = i + 1 푛 퐿 = 푑1 ∪ 표푢푡(퐿) out 푔푒푛 (퐿) = {푑2} 푘푙푙 (퐿) = {푑1} 표푢푡(퐿) = 푔푒푛(퐿) ∪ {푛(퐿) − 푘푙푙(퐿)} 푛(퐿) depends on 표푢푡(퐿), and 표푢푡(퐿) depends on 푛(퐿)!! 2012/3/2 \course\cpeg421-08s\Topic4-a.ppt 25 Initialization Solution? out[L] = First iteration d1 : i = 0 표푢푡 퐿 = 푔푒푛 퐿 ∪ ( 푛 (퐿) − 푘푙푙 퐿 ) in = {푑2} ∪ ({푑1} − {푑1}) = {푑2} loop L .
Load more

Recommended publications
  • Redundancy Elimination Common Subexpression Elimination
    Redundancy Elimination Aim: Eliminate redundant operations in dynamic execution Why occur? Loop-invariant code: Ex: constant assignment in loop Same expression computed Ex: addressing Value numbering is an example Requires dataflow analysis Other optimizations: Constant subexpression elimination Loop-invariant code motion Partial redundancy elimination Common Subexpression Elimination Replace recomputation of expression by use of temp which holds value Ex. (s1) y := a + b Ex. (s1) temp := a + b (s1') y := temp (s2) z := a + b (s2) z := temp Illegal? How different from value numbering? Ex. (s1) read(i) (s2) j := i + 1 (s3) k := i i + 1, k+1 (s4) l := k + 1 no cse, same value number Why need temp? Local and Global ¡ Local CSE (BB) Ex. (s1) c := a + b (s1) t1 := a + b (s2) d := m&n (s1') c := t1 (s3) e := a + b (s2) d := m&n (s4) m := 5 (s5) if( m&n) ... (s3) e := t1 (s4) m := 5 (s5) if( m&n) ... 5 instr, 4 ops, 7 vars 6 instr, 3 ops, 8 vars Always better? Method: keep track of expressions computed in block whose operands have not changed value CSE Hash Table (+, a, b) (&,m, n) Global CSE example i := j i := j a := 4*i t := 4*i i := i + 1 i := i + 1 b := 4*i t := 4*i b := t c := 4*i c := t Assumes b is used later ¡ Global CSE An expression e is available at entry to B if on every path p from Entry to B, there is an evaluation of e at B' on p whose values are not redefined between B' and B.
    [Show full text]
  • Integrating Program Optimizations and Transformations with the Scheduling of Instruction Level Parallelism*
    Integrating Program Optimizations and Transformations with the Scheduling of Instruction Level Parallelism* David A. Berson 1 Pohua Chang 1 Rajiv Gupta 2 Mary Lou Sofia2 1 Intel Corporation, Santa Clara, CA 95052 2 University of Pittsburgh, Pittsburgh, PA 15260 Abstract. Code optimizations and restructuring transformations are typically applied before scheduling to improve the quality of generated code. However, in some cases, the optimizations and transformations do not lead to a better schedule or may even adversely affect the schedule. In particular, optimizations for redundancy elimination and restructuring transformations for increasing parallelism axe often accompanied with an increase in register pressure. Therefore their application in situations where register pressure is already too high may result in the generation of additional spill code. In this paper we present an integrated approach to scheduling that enables the selective application of optimizations and restructuring transformations by the scheduler when it determines their application to be beneficial. The integration is necessary because infor- mation that is used to determine the effects of optimizations and trans- formations on the schedule is only available during instruction schedul- ing. Our integrated scheduling approach is applicable to various types of global scheduling techniques; in this paper we present an integrated algorithm for scheduling superblocks. 1 Introduction Compilers for multiple-issue architectures, such as superscalax and very long instruction word (VLIW) architectures, axe typically divided into phases, with code optimizations, scheduling and register allocation being the latter phases. The importance of integrating these latter phases is growing with the recognition that the quality of code produced for parallel systems can be greatly improved through the sharing of information.
    [Show full text]
  • Copy Propagation Optimizations for VLIW DSP Processors with Distributed Register Files ?
    Copy Propagation Optimizations for VLIW DSP Processors with Distributed Register Files ? Chung-Ju Wu Sheng-Yuan Chen Jenq-Kuen Lee Department of Computer Science National Tsing-Hua University Hsinchu 300, Taiwan Email: {jasonwu, sychen, jklee}@pllab.cs.nthu.edu.tw Abstract. High-performance and low-power VLIW DSP processors are increasingly deployed on embedded devices to process video and mul- timedia applications. For reducing power and cost in designs of VLIW DSP processors, distributed register files and multi-bank register archi- tectures are being adopted to eliminate the amount of read/write ports in register files. This presents new challenges for devising compiler op- timization schemes for such architectures. In our research work, we ad- dress the compiler optimization issues for PAC architecture, which is a 5-way issue DSP processor with distributed register files. We show how to support an important class of compiler optimization problems, known as copy propagations, for such architecture. We illustrate that a naive deployment of copy propagations in embedded VLIW DSP processors with distributed register files might result in performance anomaly. In our proposed scheme, we derive a communication cost model by clus- ter distance, register port pressures, and the movement type of register sets. This cost model is used to guide the data flow analysis for sup- porting copy propagations over PAC architecture. Experimental results show that our schemes are effective to prevent performance anomaly with copy propagations over embedded VLIW DSP processors with dis- tributed files. 1 Introduction Digital signal processors (DSPs) have been found widely used in an increasing number of computationally intensive applications in the fields such as mobile systems.
    [Show full text]
  • Garbage Collection
    Topic 10: Dataflow Analysis COS 320 Compiling Techniques Princeton University Spring 2016 Lennart Beringer 1 Analysis and Transformation analysis spans multiple procedures single-procedure-analysis: intra-procedural Dataflow Analysis Motivation Dataflow Analysis Motivation r2 r3 r4 Assuming only r5 is live-out at instruction 4... Dataflow Analysis Iterative Dataflow Analysis Framework Definitions Iterative Dataflow Analysis Framework Definitions for Liveness Analysis Definitions for Liveness Analysis Remember generic equations: -- r1 r1 r2 r2, r3 r3 r2 r1 r1 -- r3 -- -- Smart ordering: visit nodes in reverse order of execution. -- r1 r1 r2 r2, r3 r3 r2 r1 r3, r1 ? r1 -- r3 r3, r1 r3 -- -- r3 Smart ordering: visit nodes in reverse order of execution. -- r1 r3, r1 r3 r1 r2 r3, r2 r3, r1 r2, r3 r3 r3, r2 r3, r2 r2 r1 r3, r1 r3, r2 ? r1 -- r3 r3, r1 r3 -- -- r3 Smart ordering: visit nodes in reverse order of execution. -- r1 r3, r1 r3 r1 r2 r3, r2 r3, r1 : r2, r3 r3 r3, r2 r3, r2 r2 r1 r3, r1 r3, r2 : r1 -- r3 r3, r1 r3, r1 r3 -- -- r3 -- r3 Smart ordering: visit nodes in reverse order of execution. Live Variable Application 1: Register Allocation Interference Graph r1 r3 ? r2 Interference Graph r1 r3 r2 Live Variable Application 2: Dead Code Elimination of the form of the form Live Variable Application 2: Dead Code Elimination of the form This may lead to further optimization opportunities, as uses of variables in s of the form disappear. repeat all / some analysis / optimization passes! Reaching Definition Analysis Reaching Definition Analysis (details on next slide) Reaching definitions: definition-ID’s 1.
    [Show full text]
  • Phase-Ordering in Optimizing Compilers
    Phase-ordering in optimizing compilers Matthieu Qu´eva Kongens Lyngby 2007 IMM-MSC-2007-71 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 [email protected] www.imm.dtu.dk Summary The “quality” of code generated by compilers largely depends on the analyses and optimizations applied to the code during the compilation process. While modern compilers could choose from a plethora of optimizations and analyses, in current compilers the order of these pairs of analyses/transformations is fixed once and for all by the compiler developer. Of course there exist some flags that allow a marginal control of what is executed and how, but the most important source of information regarding what analyses/optimizations to run is ignored- the source code. Indeed, some optimizations might be better to be applied on some source code, while others would be preferable on another. A new compilation model is developed in this thesis by implementing a Phase Manager. This Phase Manager has a set of analyses/transformations available, and can rank the different possible optimizations according to the current state of the intermediate representation. Based on this ranking, the Phase Manager can decide which phase should be run next. Such a Phase Manager has been implemented for a compiler for a simple imper- ative language, the while language, which includes several Data-Flow analyses. The new approach consists in calculating coefficients, called metrics, after each optimization phase. These metrics are used to evaluate where the transforma- tions will be applicable, and are used by the Phase Manager to rank the phases.
    [Show full text]
  • Using Program Analysis for Optimization
    Analysis and Optimizations • Program Analysis – Discovers properties of a program Using Program Analysis • Optimizations – Use analysis results to transform program for Optimization – Goal: improve some aspect of program • numbfber of execute diid instructions, num bflber of cycles • cache hit rate • memory space (d(code or data ) • power consumption – Has to be safe: Keep the semantics of the program Control Flow Graph Control Flow Graph entry int add(n, k) { • Nodes represent computation s = 0; a = 4; i = 0; – Each node is a Basic Block if (k == 0) b = 1; s = 0; a = 4; i = 0; k == 0 – Basic Block is a sequence of instructions with else b = 2; • No branches out of middle of basic block while (i < n) { b = 1; b = 2; • No branches into middle of basic block s = s + a*b; • Basic blocks should be maximal ii+1;i = i + 1; i < n } – Execution of basic block starts with first instruction return s; s = s + a*b; – Includes all instructions in basic block return s } i = i + 1; • Edges represent control flow Two Kinds of Variables Basic Block Optimizations • Temporaries introduced by the compiler • Common Sub- • Copy Propagation – Transfer values only within basic block Expression Elimination – a = x+y; b = a; c = b+z; – Introduced as part of instruction flattening – a = (x+y)+z; b = x+y; – a = x+y; b = a; c = a+z; – Introduced by optimizations/transformations – t = x+y; a = t+z;;; b = t; • Program variables • Constant Propagation • Dead Code Elimination – x = 5; b = x+y; – Decldiiillared in original program – a = x+y; b = a; c = a+z; – x = 5; b
    [Show full text]
  • CSE 401/M501 – Compilers
    CSE 401/M501 – Compilers Dataflow Analysis Hal Perkins Autumn 2018 UW CSE 401/M501 Autumn 2018 O-1 Agenda • Dataflow analysis: a framework and algorithm for many common compiler analyses • Initial example: dataflow analysis for common subexpression elimination • Other analysis problems that work in the same framework • Some of these are the same optimizations we’ve seen, but more formally and with details UW CSE 401/M501 Autumn 2018 O-2 Common Subexpression Elimination • Goal: use dataflow analysis to A find common subexpressions m = a + b n = a + b • Idea: calculate available expressions at beginning of B C p = c + d q = a + b each basic block r = c + d r = c + d • Avoid re-evaluation of an D E available expression – use a e = b + 18 e = a + 17 copy operation s = a + b t = c + d u = e + f u = e + f – Simple inside a single block; more complex dataflow analysis used F across bocks v = a + b w = c + d x = e + f G y = a + b z = c + d UW CSE 401/M501 Autumn 2018 O-3 “Available” and Other Terms • An expression e is defined at point p in the CFG if its value a+b is computed at p defined t1 = a + b – Sometimes called definition site ... • An expression e is killed at point p if one of its operands a+b is defined at p available t10 = a + b – Sometimes called kill site … • An expression e is available at point p if every path a+b leading to p contains a prior killed b = 7 definition of e and e is not … killed between that definition and p UW CSE 401/M501 Autumn 2018 O-4 Available Expression Sets • To compute available expressions, for each block
    [Show full text]
  • Machine Independent Code Optimizations
    Machine Independent Code Optimizations Useless Code and Redundant Expression Elimination cs5363 1 Code Optimization Source IR IR Target Front end optimizer Back end program (Mid end) program compiler The goal of code optimization is to Discover program run-time behavior at compile time Use the information to improve generated code Speed up runtime execution of compiled code Reduce the size of compiled code Correctness (safety) Optimizations must preserve the meaning of the input code Profitability Optimizations must improve code quality cs5363 2 Applying Optimizations Most optimizations are separated into two phases Program analysis: discover opportunity and prove safety Program transformation: rewrite code to improve quality The input code may benefit from many optimizations Every optimization acts as a filtering pass that translate one IR into another IR for further optimization Compilers Select a set of optimizations to implement Decide orders of applying implemented optimizations The safety of optimizations depends on results of program analysis Optimizations often interact with each other and need to be combined in specific ways Some optimizations may need to applied multiple times . E.g., dead code elimination, redundancy elimination, copy folding Implement predetermined passes of optimizations cs5363 3 Scalar Compiler Optimizations Machine independent optimizations Enable other transformations Procedure inlining, cloning, loop unrolling Eliminate redundancy Redundant expression elimination Eliminate useless
    [Show full text]
  • Code Improvement:Thephasesof Compilation Devoted to Generating Good Code
    Code17 Improvement In Chapter 15 we discussed the generation, assembly, and linking of target code in the middle and back end of a compiler. The techniques we presented led to correct but highly suboptimal code: there were many redundant computations, and inefficient use of the registers, multiple functional units, and cache of a mod- ern microprocessor. This chapter takes a look at code improvement:thephasesof compilation devoted to generating good code. For the most part we will interpret “good” to mean fast. In a few cases we will also consider program transforma- tions that decrease memory requirements. On occasion a real compiler may try to minimize power consumption, dollar cost of execution under a particular ac- counting system, or demand for some other resource; we will not consider these issues here. There are several possible levels of “aggressiveness” in code improvement. In a very simple compiler, or in a “nonoptimizing” run of a more sophisticated com- piler, we can use a peephole optimizer to peruse already-generated target code for obviously suboptimal sequences of adjacent instructions. At a slightly higher level, typical of the baseline behavior of production-quality compilers, we can generate near-optimal code for basic blocks. As described in Chapter 15, a basic block is a maximal-length sequence of instructions that will always execute in its entirety (assuming it executes at all). In the absence of delayed branches, each ba- sic block in assembly language or machine code begins with the target of a branch or with the instruction after a conditional branch, and ends with a branch or with the instruction before the target of a branch.
    [Show full text]
  • Abstract Interpretations, 14 Access Expressions, 137 Access Graph
    Index abstract interpretations, 14 φ placement, 196 access expressions, 137 dominance frontier, 194 access graph, 141 renaming, 199 empty, 141 SSA destruction, 214 operations, 143–146 register allocation, 224 cleanUp, 143 alias analysis, 129–135 CN, 143 data flow equations, 134 extension, 145 of parameters, 268 factorization, 145 data flow equations, 269–271 field, 143 alias relations, 129 lastNode, 143 aliasing makeGraph, 143 data flow equations, 134 path removal, 145 direct aliases, 131 root, 143 indirect aliases, 131 safety of, 146 link aliases, 130 union, 144 node aliases, 130 summarization, 142 of access paths, 3, 9 access path, 3, 137 of parameters, 267 aliasing of, 3 of pointers, 2, 129–135 base of, 137 all paths analysis, 33 directly generated, 139 anti-symmetric, 64 frontier of, 137 anticipable expressions analysis, 37–39 killed, 139 data flow equations, 38 liveness of, 3 any path analysis, 26 simple, 137 applications of data flow analysis, 16 summarization, 3, 12 assignment, 176, 177, 181 target of, 137 maximum fixed point (MFP), 77 transfer of, 139 maximum safe, 75 algorithm meet over paths (MOP), 75 DFST construction, 60 associativity, 66 elimination, 184 available expressions analysis, 33–35 iterative common subexpressions elimination, round-robin, 4, 19, 79, 90, 163– 34 164 data flow equations, 33 work list, 165–172,312, 319, 320, 322 backward data flow problem, 26 SSA construction backward edges, 61 379 380 Index backward flow, 24, 160 termination length, 328 basic block, 23 termination, issues in, 305–310 bidirectional data flow equations,
    [Show full text]
  • Compiler Construction
    Compiler construction PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 10 Dec 2011 02:23:02 UTC Contents Articles Introduction 1 Compiler construction 1 Compiler 2 Interpreter 10 History of compiler writing 14 Lexical analysis 22 Lexical analysis 22 Regular expression 26 Regular expression examples 37 Finite-state machine 41 Preprocessor 51 Syntactic analysis 54 Parsing 54 Lookahead 58 Symbol table 61 Abstract syntax 63 Abstract syntax tree 64 Context-free grammar 65 Terminal and nonterminal symbols 77 Left recursion 79 Backus–Naur Form 83 Extended Backus–Naur Form 86 TBNF 91 Top-down parsing 91 Recursive descent parser 93 Tail recursive parser 98 Parsing expression grammar 100 LL parser 106 LR parser 114 Parsing table 123 Simple LR parser 125 Canonical LR parser 127 GLR parser 129 LALR parser 130 Recursive ascent parser 133 Parser combinator 140 Bottom-up parsing 143 Chomsky normal form 148 CYK algorithm 150 Simple precedence grammar 153 Simple precedence parser 154 Operator-precedence grammar 156 Operator-precedence parser 159 Shunting-yard algorithm 163 Chart parser 173 Earley parser 174 The lexer hack 178 Scannerless parsing 180 Semantic analysis 182 Attribute grammar 182 L-attributed grammar 184 LR-attributed grammar 185 S-attributed grammar 185 ECLR-attributed grammar 186 Intermediate language 186 Control flow graph 188 Basic block 190 Call graph 192 Data-flow analysis 195 Use-define chain 201 Live variable analysis 204 Reaching definition 206 Three address
    [Show full text]
  • Optimization.Pdf
    1. statement-by-statement code generation 2. peephole optimization 3. “global” optimization 0-0 Peephole optimization Peephole: a short sequence of target instructions that may be replaced by a shorter/faster sequence One optimization may make further optimizations possible ) several passes may be required 1. Redundant load/store elimination: 9.9 MOV R0 a MOV a R0 delete if in same B.B. 2. Algebraic simplification: eliminate instructions like the Section following: x = x + 0 x = x * 1 3. Strength reduction: replace expensive operations by equivalent cheaper operations, e.g. x2 ! x * x fixed-point multiplication/division by power of 2 ! shift Compiler Construction: Code Optimization – p. 1/35 Peephole optimization 4. Jumps: goto L1 if a < b goto L1 ... ... L1: goto L2 L1: goto L2 + + goto L2 if a < b goto L2 ... ... L1: goto L2 L1: goto L2 If there are no other jumps to L1, and it is preceded by an unconditional jump, it may be eliminated. If there is only jump to L1 and it is preceded by an unconditional goto goto L1 if a < b goto L2 ... goto L3 L1: if a < b goto L2 ) ... L3: L3: Compiler Construction: Code Optimization – p. 2/35 Peephole optimization 5. Unreachable code: unlabeled instruction following an unconditional jump may be eliminated #define DEBUG 0 if debug = 1 goto L1 ... goto L2 if (debug) { ) L1: /* print */ /* print stmts */ L2: } + if 0 != 1 goto L2 if debug != 1 goto L2 /* print stmts */ ( /* print stmts */ L2: L2: eliminate Compiler Construction: Code Optimization – p. 3/35 Example i = m-1; j = n; v = a[n]; while (1) { do i = i+1; while (a[i] < v); do j = j-1; while (a[j] > v); if (i >= j) break; x = a[i]; a[i] = a[j]; a[j] = x; } 10.1 x = a[i]; a[i] = a[n]; a[n] = x; Section Compiler Construction: Code Optimization – p.
    [Show full text]