DOCSLIB.ORG

Lecture 17 1) Profile-Based Compiler: High-Level  Binary, Static – Dynamic Code Optimization Uses (Dynamic=Runtime) Information Collected in Profiling Passes

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Lecture 17 1) Profile-Based Compiler: High-Level  Binary, Static – Dynamic Code Optimization Uses (Dynamic=Runtime) Information Collected in Profiling Passes I. Beyond Static Compilation Lecture 17 1) Profile-based Compiler: high-level binary, static – Dynamic Code Optimization Uses (dynamic=runtime) information collected in profiling passes I. Motivation & Background 2) Interpreter: high-level, emulate, dynamic II. Overview III. Partial Method Compilation 3) Dynamic compilation / code optimization: high-level binary, dynamic IV. Partial Dead Code Elimination – interpreter/compiler hybrid V. Partial Escape Analysis – supports cross-module optimization VI. Results – can specialize program using runtime information “Partial Method Compilation Using Dynamic Profile Information”, • without separate profiling passes John Whaley, OOPSLA 01 Carnegie Mellon Carnegie Mellon Phillip B. Gibbons 15-745: Dynamic Code Optimization 1 15-745: Dynamic Code Optimization 2 1) Dynamic Profiling Can Improve Compile-time Optimizations Profile-Based Compile-time Optimization • Understanding common dynamic behaviors may help guide optimizations 1. Compile statically 2. Collect profile 3. Re-compile, using profile – e.g., control flow, data dependences, input values (using typical inputs) void foo(int A, int B) { prog1.c prog1.c … What are typical values of A, B? input1 while (…) { How often is this condition true? execution if (A > B) profile runme.exe How often does *p == val[i]? compiler compiler *p = 0; (instrumented) C = val[i] + D; Is this loop invariant? E += C – B; execution … runme.exe runme_v2.exe profile } } • Collecting control-flow profiles is relatively inexpensive • Profile-based compile-time optimizations – profiling data dependences, data values, etc., is more costly – e.g., speculative scheduling, cache optimizations, code specialization • Limitations of this approach? Carnegie Mellon Carnegie Mellon 15-745: Dynamic Code Optimization 3 15-745: Dynamic Code Optimization 4 1 Instrumenting Executable Binaries Binary Instrumentation/Optimization Tools 1. Compile statically 2. Collect profile • Unlike typical compilation, the input is a binary (not source code) (using typical inputs) • One option: static binary-to-binary rewriting prog1.c input1 runme.exe tool runme_modified.exe How to perform the instrumentation? • Challenges (with the static approach): compiler runme.exe (instrumented) – what about dynamically-linked shared libraries? binary – if our goal is optimization, are we likely to make the code faster? execution runme.exe instrumentation • a compiler already tried its best, and it had source code (we don’t) profile tool – if we are adding instrumentation code, what about time/space overheads? 1. The compiler could insert it directly • instrumented code might be slow & bloated if we aren’t careful 2. A binary instrumentation tool could modify the executable directly • optimization may be needed just to keep these overheads under control – that way, we don’t need to modify the compiler – compilers that target the same architecture (e.g., x86) can use the same tool • Bottom line: the purely static approach to binary rewriting is rarely used Carnegie Mellon Carnegie Mellon 15-745: Dynamic Code Optimization 5 15-745: Dynamic Code Optimization 6 2) (Pure) Interpreter A Sweet Spot? • One approach to dynamic code execution/analysis is an interpreter • Is there a way that we can combine: – basic idea: a software loop that grabs, decodes, and emulates each instruction – the flexibility of an interpreter (analyzing and changing code dynamically); and while (stillExecuting) { – the performance of direct hardware execution? inst = readInst(PC); instInfo = decodeInst(inst); switch (instInfo.opType) { • Key insights: case binaryArithmetic: … – increase the granularity of interpretation case memoryLoad: … … • instructions chunks of code (e.g., procedures, basic blocks) } – dynamically compile these chunks into directly-executed optimized code PC = nextPC(PC,instInfo); } • store these compiled chunks in a software code cache • Advantages: • jump in and out of these cached chunks when appropriate – also works for dynamic programming languages (e.g., Java) • these cached code chunks can be updated! – easy to change the way we execute code on-the-fly (SW controls everything) – invest more time optimizing code chunks that are clearly hot/important • Disadvantages: • easy to instrument the code, since already rewriting it – runtime overhead! • must balance (dynamic) compilation time with likely benefits • each dynamic instruction is emulated individually by software Carnegie Mellon Carnegie Mellon 15-745: Dynamic Code Optimization 7 15-745: Dynamic Code Optimization 8 2 3) Dynamic Compiler Components in a Typical Just-In-Time (JIT) Compiler while (stillExecuting) { Dynamic Code if (!codeCompiledAlready(PC)) { Optimizer compileChunkAndInsertInCache(PC); } “Interpreter” Compiled Code jumpIntoCodeCache(PC); Input Profiling // compiled chunk returns here when finished Program Control Loop Cache (Chunks) Information PC = getNextPC(…); } Cache Manager (Eviction Policy) • This general approach is widely used: – Java virtual machines • Cached chunks of compiled code run at hardware speed – dynamic binary instrumentation tools (Valgrind, Pin, Dynamo Rio) – returns control to “interpreter” loop when chunk is finished – hardware virtualization • Dynamic optimizer uses profiling information to guide code optimization – as code becomes hotter, more aggressive optimization is justified replace the old compiled code chunk with a faster version Carnegie Mellon Carnegie Mellon 15-745: Dynamic Code Optimization 9 15-745: Dynamic Code Optimization 10 II. Overview of Dynamic Compilation / Code Optimization Dynamic Compilation Policy • Interpretation/Compilation/Optimization policy decisions • ∆Ttotal = Tcompile – (nexecutions * Timprovement) – Choosing what and how to compile, and how much to optimize – If ∆Ttotal is negative, our compilation policy decision was effective. • Collecting runtime information – Instrumentation • We can try to: – Sampling – Reduce Tcompile (faster compile times) – Increase T (generate better code: but at cost of increasing T ) • Optimizations exploiting runtime information improvement compile – Focus on large nexecutions (compile/optimize hot spots) – Focus on frequently-executed code paths • 80/20 rule: Pareto Principle – 20% of the work for 80% of the advantage Carnegie Mellon Carnegie Mellon 15-745: Dynamic Code Optimization 11 15-745: Dynamic Code Optimization 12 3 Latency vs. Throughput Multi-Stage Dynamic Compilation System • Tradeoff: startup speed vs. execution performance interpreted Execution count is the sum of Stage 1: method invocations & back edges executed code Startup speed Execution performance when execution count = t1 (e.g. 2000) Interpreter Best Poor ‘Quick’ compiler Fair Fair compiled Stage 2: Optimizing compiler Poor Best code when execution count = t2 (e.g. 25,000) fully optimized Stage 3: code Carnegie Mellon Carnegie Mellon 15-745: Dynamic Code Optimization 13 15-745: Dynamic Code Optimization 14 Granularity of Compilation: Per Method? Example: SpecJVM98 db • Methods can be large, especially after inlining void read_db(String fn) { – Cutting/avoiding inlining too much hurts performance considerably int n = 0, act = 0; int b; byte buffer[] = null; try { FileInputStream sif = new FileInputStream(fn); • Compilation time is proportional to the amount of code being compiled n = sif.getContentLength(); – Moreover, many optimizations are not linear buffer = new byte[n]; Hot while ((b = sif.read(buffer, act, n-act))>0) { • Even “hot” methods typically contain some code that is rarely/never executed act = act + b; loop } sif.close(); if (act != n) { /* lots of error handling code, rare */ } } catch (IOException ioe) { /* lots of error handling code, rare */ } Carnegie Mellon } Carnegie Mellon 15-745: Dynamic Code Optimization 15 15-745: Dynamic Code Optimization 16 4 Example: SpecJVM98 db Optimize hot “regions”, not methods void read_db(String fn) { interpreted int n = 0, act = 0; int b; byte buffer[] = null; • Optimize only the most frequently executed Stage 1: code try { segments within a method FileInputStream sif = new FileInputStream(fn); – Simple technique: n = sif.getContentLength(); • Track execution counts of basic blocks buffer = new byte[n]; in Stages 1 & 2 while ((b = sif.read(buffer, act, n-act))>0) { • Any basic block executing in Stage 2 compiled Stage 2: act = act + b; is considered to be not rare code } Lots of sif.close(); • Beneficial secondary effect of improving if (act != n) { rare code! optimization opportunities on the common paths /* lots of error handling code, rare */ } • No need to profile any basic block executing fully optimized } catch (IOException ioe) { in Stage 3 Stage 3: code /* lots of error handling code, rare */ – Already fully optimized } } Carnegie Mellon Carnegie Mellon 15-745: Dynamic Code Optimization 17 15-745: Dynamic Code Optimization 18 % of Basic Blocks in Methods that are Executed > Threshold Times % of Basic Blocks that are Executed > Threshold Times (hence would get compiled under per-method strategy) (hence get compiled under per-basic-block strategy) 100.00% 100.00% Linpack Linpack JavaC UP JavaC UP 80.00% 80.00% JavaLEX JavaLEX SwingSet S wingSet 60.00% check 60.00% check com press com press 40.00% jess 40.00% jess db db javac javac 20.00% 20.00% m pegaud m pegaud % of basic executed % of blocks % of basic compiled % of blocks m trt m trt 0.00% jack 0.00% jack 1 10 100 500 1000 2000 5000 1 10 100 500 1000 2000 5000 execution threshold execution threshold Carnegie Mellon Carnegie Mellon 15-745: Dynamic Code Optimization
Load more

Recommended publications
  • Control Flow Analysis in Scheme
    Control Flow Analysis in Scheme Olin Shivers Carnegie Mellon University [email protected] Abstract Fortran). Representative texts describing these techniques are [Dragon], and in more detail, [Hecht]. Flow analysis is perhaps Traditional ¯ow analysis techniques, such as the ones typically the chief tool in the optimising compiler writer's bag of tricks; employed by optimising Fortran compilers, do not work for an incomplete list of the problems that can be addressed with Scheme-like languages. This paper presents a ¯ow analysis ¯ow analysis includes global constant subexpression elimina- technique Ð control ¯ow analysis Ð which is applicable to tion, loop invariant detection, redundant assignment detection, Scheme-like languages. As a demonstration application, the dead code elimination, constant propagation, range analysis, information gathered by control ¯ow analysis is used to per- code hoisting, induction variable elimination, copy propaga- form a traditional ¯ow analysis problem, induction variable tion, live variable analysis, loop unrolling, and loop jamming. elimination. Extensions and limitations are discussed. However, these traditional ¯ow analysis techniques have The techniques presented in this paper are backed up by never successfully been applied to the Lisp family of computer working code. They are applicable not only to Scheme, but languages. This is a curious omission. The Lisp community also to related languages, such as Common Lisp and ML. has had suf®cient time to consider the problem. Flow analysis dates back at least to 1960, ([Dragon], pp. 516), and Lisp is 1 The Task one of the oldest computer programming languages currently in use, rivalled only by Fortran and COBOL. Flow analysis is a traditional optimising compiler technique Indeed, the Lisp community has long been concerned with for determining useful information about a program at compile the execution speed of their programs.
    [Show full text]
  • Language and Compiler Support for Dynamic Code Generation by Massimiliano A
    Language and Compiler Support for Dynamic Code Generation by Massimiliano A. Poletto S.B., Massachusetts Institute of Technology (1995) M.Eng., Massachusetts Institute of Technology (1995) Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Doctor of Philosophy at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY September 1999 © Massachusetts Institute of Technology 1999. All rights reserved. A u th or ............................................................................ Department of Electrical Engineering and Computer Science June 23, 1999 Certified by...............,. ...*V .,., . .* N . .. .*. *.* . -. *.... M. Frans Kaashoek Associate Pro essor of Electrical Engineering and Computer Science Thesis Supervisor A ccepted by ................ ..... ............ ............................. Arthur C. Smith Chairman, Departmental CommitteA on Graduate Students me 2 Language and Compiler Support for Dynamic Code Generation by Massimiliano A. Poletto Submitted to the Department of Electrical Engineering and Computer Science on June 23, 1999, in partial fulfillment of the requirements for the degree of Doctor of Philosophy Abstract Dynamic code generation, also called run-time code generation or dynamic compilation, is the cre- ation of executable code for an application while that application is running. Dynamic compilation can significantly improve the performance of software by giving the compiler access to run-time infor- mation that is not available to a traditional static compiler. A well-designed programming interface to dynamic compilation can also simplify the creation of important classes of computer programs. Until recently, however, no system combined efficient dynamic generation of high-performance code with a powerful and portable language interface. This thesis describes a system that meets these requirements, and discusses several applications of dynamic compilation.
    [Show full text]
  • Strength Reduction of Induction Variables and Pointer Analysis – Induction Variable Elimination
    Loop optimizations • Optimize loops – Loop invariant code motion [last time] Loop Optimizations – Strength reduction of induction variables and Pointer Analysis – Induction variable elimination CS 412/413 Spring 2008 Introduction to Compilers 1 CS 412/413 Spring 2008 Introduction to Compilers 2 Strength Reduction Induction Variables • Basic idea: replace expensive operations (multiplications) with • An induction variable is a variable in a loop, cheaper ones (additions) in definitions of induction variables whose value is a function of the loop iteration s = 3*i+1; number v = f(i) while (i<10) { while (i<10) { j = 3*i+1; //<i,3,1> j = s; • In compilers, this a linear function: a[j] = a[j] –2; a[j] = a[j] –2; i = i+2; i = i+2; f(i) = c*i + d } s= s+6; } •Observation:linear combinations of linear • Benefit: cheaper to compute s = s+6 than j = 3*i functions are linear functions – s = s+6 requires an addition – Consequence: linear combinations of induction – j = 3*i requires a multiplication variables are induction variables CS 412/413 Spring 2008 Introduction to Compilers 3 CS 412/413 Spring 2008 Introduction to Compilers 4 1 Families of Induction Variables Representation • Basic induction variable: a variable whose only definition in the • Representation of induction variables in family i by triples: loop body is of the form – Denote basic induction variable i by <i, 1, 0> i = i + c – Denote induction variable k=i*a+b by triple <i, a, b> where c is a loop-invariant value • Derived induction variables: Each basic induction variable i defines
    [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]
  • Hybrid Analysis of Memory References And
    HYBRID ANALYSIS OF MEMORY REFERENCES AND ITS APPLICATION TO AUTOMATIC PARALLELIZATION A Dissertation by SILVIUS VASILE RUS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY December 2006 Major Subject: Computer Science HYBRID ANALYSIS OF MEMORY REFERENCES AND ITS APPLICATION TO AUTOMATIC PARALLELIZATION A Dissertation by SILVIUS VASILE RUS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Approved by: Chair of Committee, Lawrence Rauchwerger Committee Members, Nancy Amato Narasimha Reddy Vivek Sarin Head of Department, Valerie Taylor December 2006 Major Subject: Computer Science iii ABSTRACT Hybrid Analysis of Memory References and Its Application to Automatic Parallelization. (December 2006) Silvius Vasile Rus, B.S., Babes-Bolyai University Chair of Advisory Committee: Dr. Lawrence Rauchwerger Executing sequential code in parallel on a multithreaded machine has been an elusive goal of the academic and industrial research communities for many years. It has recently become more important due to the widespread introduction of multi- cores in PCs. Automatic multithreading has not been achieved because classic, static compiler analysis was not powerful enough and program behavior was found to be, in many cases, input dependent. Speculative thread level parallelization was a welcome avenue for advancing parallelization coverage but its performance was not always op- timal due to the sometimes unnecessary overhead of checking every dynamic memory reference. In this dissertation we introduce a novel analysis technique, Hybrid Analysis, which unifies static and dynamic memory reference techniques into a seamless com- piler framework which extracts almost maximum available parallelism from scientific codes and incurs close to the minimum necessary run time overhead.
    [Show full text]
  • Optimization Compiler Passes Optimizations the Role of The
    Analysis Synthesis of input program of output program Compiler (front -end) (back -end) character Passes stream Intermediate Lexical Analysis Code Generation token intermediate Optimization stream form Syntactic Analysis Optimization abstract intermediate Before and after generating machine syntax tree form code, devote one or more passes over the program to “improve” code quality Semantic Analysis Code Generation annotated target AST language 2 The Role of the Optimizer Optimizations • The compiler can implement a procedure in many ways • The optimizer tries to find an implementation that is “better” – Speed, code size, data space, … Identify inefficiencies in intermediate or target code Replace with equivalent but better sequences To accomplish this, it • Analyzes the code to derive knowledge about run-time • equivalent = "has the same externally visible behavior – Data-flow analysis, pointer disambiguation, … behavior" – General term is “static analysis” Target-independent optimizations best done on IL • Uses that knowledge in an attempt to improve the code – Literally hundreds of transformations have been proposed code – Large amount of overlap between them Target-dependent optimizations best done on Nothing “optimal” about optimization target code • Proofs of optimality assume restrictive & unrealistic conditions • Better goal is to “usually improve” 3 4 Traditional Three-pass Compiler The Optimizer (or Middle End) IR Source Front Middle IR Back Machine IROpt IROpt IROpt ... IROpt IR Code End End End code 1 2 3 n Errors Errors Modern
    [Show full text]
  • CS 4120 Introduction to Compilers Andrew Myers Cornell University
    CS 4120 Introduction to Compilers Andrew Myers Cornell University Lecture 19: Introduction to Optimization 2020 March 9 Optimization • Next topic: how to generate better code through optimization. • Tis course covers the most valuable and straightforward optimizations – much more to learn! –Other sources: • Appel, Dragon book • Muchnick has 10 chapters of optimization techniques • Cooper and Torczon 2 CS 4120 Introduction to Compilers How fast can you go? 10000 direct source code interpreters (parsing included!) 1000 tokenized program interpreters (BASIC, Tcl) AST interpreters (Perl 4) 100 bytecode interpreters (Java, Perl 5, OCaml, Python) call-threaded interpreters 10 pointer-threaded interpreters (FORTH) simple code generation (PA4, JIT) 1 register allocation naive assembly code local optimization global optimization FPGA expert assembly code GPU 0.1 3 CS 4120 Introduction to Compilers Goal of optimization • Compile clean, modular, high-level source code to expert assembly-code performance. • Can’t change meaning of program to behavior not allowed by source. • Different goals: –space optimization: reduce memory use –time optimization: reduce execution time –power optimization: reduce power usage 4 CS 4120 Introduction to Compilers Why do we need optimization? • Programmers may write suboptimal code for clarity. • Source language may make it hard to avoid redundant computation a[i][j] = a[i][j] + 1 • Architectural independence • Modern architectures assume optimization—hard to optimize by hand! 5 CS 4120 Introduction to Compilers Where to optimize? • Usual goal: improve time performance • But: many optimizations trade off space vs. time. • Example: loop unrolling replaces a loop body with N copies. –Increasing code space speeds up one loop but slows rest of program down a little.
    [Show full text]
  • Iterative Dataflow Analysis
    Iterative Dataflow Analysis ¯ Many dataflow analyses have the same structure. ¯ They “interpret” the statements in program, collecting information as they proceed. ¯ Ideally, we would like to do “perfect interpretation,” collecting exact information about how the program executes. ¯ We can’t because we don’t have the program inputs at compile time, and we aren’t going to make our compiler run the program to completion during compilation–that just takes too long (why the hell do you think we are compiling the program in the first place?) Computer Science 320 Prof. David Walker -1- Iterative Dataflow Analysis ¯ Instead of interpreting the program exactly, we approximate the program behavior as we execute. ¯ This is called Abstract Interpretation and it is often a useful way of understanding different program analyses. ¯ Analysis via abstract interpretation is often defined by: – A transfer function — ´Òµ — that simulates/approximates execution of instruc- tion Ò on its inputs – A joining operator — — since you don’t know which branch of an if state- ment (for example) will be taken at compile time, you need to interpret both and combine the results. – A direction — FORWARD or REVERSE — In the reverse direction, we are interpreting the program backwards. Computer Science 320 Prof. David Walker -2- Iterative Dataflow Analysis To code up a particular analysis we need to take the following steps. ¯ First, we decide what sort of information we are interested in processing. This is going to determine the transfer function and the joining operator, as well as any initial conditions that need to be set up. ¯ Second, we decide on the appropriate direction for the analysis.
    [Show full text]
  • Linear Scan Register Allocation
    Linear Scan Register Allocation MASSIMILIANO POLETTO Laboratory for Computer Science, MIT and VIVEK SARKAR IBM Thomas J. Watson Research Center We describe a new algorithm for fast global register allocation called linear scan. This algorithm is not based on graph coloring, but allocates registers to variables in a single linear-time scan of the variables’ live ranges. The linear scan algorithm is considerably faster than algorithms based on graph coloring, is simple to implement, and results in code that is almost as efficient as that obtained using more complex and time-consuming register allocators based on graph coloring. The algorithm is of interest in applications where compile time is a concern, such as dynamic compilation systems, “just-in-time” compilers, and interactive development environments. Categories and Subject Descriptors: D.3.4 [Programming Languages]: Processors—compilers; code generation; optimization General Terms: Algorithms, Performance Additional Key Words and Phrases: Code optimization, compilers, register allocation 1. INTRODUCTION Register allocation is an important optimization affecting the performance of com- piled code. For example, good register allocation can improve the performance of several SPEC benchmarks by an order of magnitude relative to when they are compiled with poor or no register allocation. Unfortunately, most aggressive global register allocation algorithms are computationally expensive due to their use of the graph coloring framework [Chaitin et al. 1981], in which the interference graph can have a worst-case size that is quadratic in the number of live ranges. We describe a global register allocation algorithm, called linear scan,thatisnot based on graph coloring. Rather, given the live ranges of variables in a function, the algorithm scans all the live ranges in a single pass, allocating registers to variables in a greedy fashion.
    [Show full text]
  • Data Flow Analysis
    Data Flow Analysis Baishakhi Ray Columbia University Adopted From U Penn CIS 570: Modern Programming Language Implementation (Autumn 2006) Data flow analysis • Derives information about the dynamic 1 a := 0 behavior of a program by only examining 2 L1: b := a + 1 the static code 3 c := c + b • Intraprocedural analysis 4 a := b * 2 • Flow-sensitive: sensitive to the 5 if a < 9 goto L1 control flow in a function 6 return c • Examples • How many registers do we need? – Live variable analysis • Easy bound: # of used variables – Constant propagation (3) – Common subexpression elimination • Need better answer – Dead code detection Data flow analysis • Statically: finite program • Dynamically: can have infinitely many paths • Data flow analysis abstraction • For each point in the program, combines information of all instances of the same program point Example 1: Liveness Analysis Liveness Analysis Definition –A variable is live at a particular point in the program if its value at that point will be used in the future (dead, otherwise). –To compute liveness at a given point, we need to look into the future Motivation: Register Allocation –A program contains an unbounded number of variables – Must execute on a machine with a bounded number of registers –Tw o v a r i a b l e s can use the same register if they are never in use at the same time (i.e, never simultaneously live). –Register allocation uses liveness information Control Flow Graph • Let’s consider CFG where nodes contain program 1. a = 0 statement instead of basic block. 2. b = a + 1 • Example 3.
    [Show full text]
  • Binary Translation to Improve Energy Efficiency Through Post-Pass
    Binary Translation to Improve Energy Efficiency through Post-pass Register Re-allocation Kun Zhang Tao Zhang Santosh Pande College of Computing Georgia Institute of Technology Atlanta, GA, 30332 {kunzhang, zhangtao, santosh}@cc.gatech.edu ABSTRACT Energy efficiency is rapidly becoming a first class optimization 1. INTRODUCTION Energy efficiency has become a first class optimization parameter parameter for modern systems. Caches are critical to the overall for both high performance processors as well as embedded performance and thus, modern processors (both high and low-end) processors; however, a very large percentage of legacy binaries tend to deploy a cache with large size and high degree of exist that are optimized for performance without any associativity. Due a large size cache power takes up a significant consideration to power. In this work, we focus on improving such percentage of total system power. One important way to reduce binaries for popular processors such as the Pentium (x86) for cache power consumption is to reduce the dynamic activities in saving power without degradation (in fact slight improvement) in the cache by reducing the dynamic load-store counts. In this work, performance. we focus on programs that are only available as binaries which need to be improved for energy efficiency. For adapting these Because cache size and organization are so critical to the overall programs for energy-constrained devices, we propose a feed-back performance of a processor, modern processors tend to deploy directed post-pass solution that tries to do register re-allocation to caches with large sizes and high degree of associativity. A large reduce dynamic load/store counts and to improve energy- cache consumes a significant part of the total processor power.
    [Show full text]
  • Data-Flow Analysis Schema
    Data-flow Analysis - Part 2 Y.N. Srikant Department of Computer Science Indian Institute of Science Bangalore 560 012 NPTEL Course on Compiler Design Y.N. Srikant Data-flow Analysis Data-flow analysis These are techniques that derive information about the flow of data along program execution paths An execution path (or path) from point p1 to point pn is a sequence of points p1; p2; :::; pn such that for each i = 1; 2; :::; n − 1, either 1 pi is the point immediately preceding a statement and pi+1 is the point immediately following that same statement, or 2 pi is the end of some block and pi+1 is the beginning of a successor block In general, there is an infinite number of paths through a program and there is no bound on the length of a path Program analyses summarize all possible program states that can occur at a point in the program with a finite set of facts No analysis is necessarily a perfect representation of the state Y.N. Srikant Data-flow Analysis Uses of Data-flow Analysis Program debugging Which are the definitions (of variables) that may reach a program point? These are the reaching definitions Program optimizations Constant folding Copy propagation Common sub-expression elimination etc. Y.N. Srikant Data-flow Analysis Data-Flow Analysis Schema A data-flow value for a program point represents an abstraction of the set of all possible program states that can be observed for that point The set of all possible data-flow values is the domain for the application under consideration Example: for the reaching definitions problem, the domain of data-flow values is the set of all subsets of of definitions in the program A particular data-flow value is a set of definitions IN[s] and OUT [s]: data-flow values before and after each statement s The data-flow problem is to find a solution to a set of constraints on IN[s] and OUT [s], for all statements s Y.N.
    [Show full text]