DOCSLIB.ORG

6.035 Lecture 9, Introduction to Program Analysis and Optimization

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Spring 20092009 Lecture 9:9: IntroductionIntroduction toto Program Analysis and Optimization Outline • Introduction • Basic Blocks • Common Subexpression Elimination • Copy P ropa gatition •Dead CCodeode Eliminatation • Algebraic Simplification • Summary Prog ram Analysis • Compile-time reasoning about run-time behavior of program – Can discover things that are always true: • “ x is al ways 1 in thth e s tatemen t y = x + z” • “the pointer p always points into array a” • “the statement return 5 can never execute” – Can infer things that are likely to be true: • “the reference r usually refers to an object of class C” • “thethe statement a=b+ca = b + c appears ttoo eexecutexecute more frequently than the statement x = y + z” – Distinction between data and control-flow properties Saman Amarasinghe 3 6.035 ©MIT Fall 1998 Transformations • Use analysis results to transform program • Overall goal: improve some aspect of program • Traditional goals: – RdReduce number of execute d i nstruct ions – Reduce overall code size • Other goalsgoals emerge as space becomesbecomes more complex – Reduce number of cycles • Use vector or DSP instructions • Improve instruction or data cache hit rate – Reduce power consumption – Reduce memory usage Saman Amarasinghe 4 6.035 ©MIT Fall 1998 Outline • Introduction • Basic Blocks • Common Subexpression Elimination • Copy P ropa gatition •Dead CCodeode Eliminatation • Algebraic Simplification • Summary Control Flow Graph • Nodes Rep resent Comp utation – Each Node is a Basic Block –Basic Block is a Seququ ence of Instructions with • No Branches Out Of Middle of Basic Block • No Branches Into Middle of Basic Block • Basic Blocks should be maximal – Execution of basic block starts with first instruction – Includes all instructions in basic block •Edges Represent Control Flow Saman Amarasinghe 6 6.035 ©MIT Fall 1998 Control Flow Grap h s = 0; a = 4; into add(n, k) { i = 0; s = 0; a = 4; i = 0; k == 0 if (k == 0) b = 1; else b = 2; b = 1; b=b = 2;2; while (i < n) { i < n s = s + a*b; s = s +*+ a*bb; i = i + 1; return s; i = i + 1; } return s; } Saman Amarasinghe 7 6.035 ©MIT Fall 1998 Basic Block Construction • Start with instruction control-flow ggpraph • Visit all edges in graph • Merge aadjacentdjacent nnodesodes if – Only one edge from first node – Only oneone edge into second node s = 0; s = 0; a = 4; a = 4; Saman Amarasinghe 8 6.035 ©MIT Fall 1998 s = 0; s = 0; a = 4; a = 4; i = 0; k==0 b = 2; b = 1; i < n s = s + a*b; return s; iii+1; = i+1; Saman Amarasinghe 9 6.035 ©MIT Fall 2006 s = 0; s = 0; a = 4; a = 4; i = 0; i = 0; k==0 b = 2; b = 1; i < n s = s + a*b; return s; iii+1; = i+1; Saman Amarasinghe 10 6.035 ©MIT Fall 2006 s = 0; s = 0; a = 4; a = 4; i = 0; k==0 i = 0; k==0 b = 2; b = 1; i < n s = s + a*b; return s; iii+1; = i+1; Saman Amarasinghe 11 6.035 ©MIT Fall 2006 s = 0; s=0; a = 4; a = 4; i = 0; k==0 i = 0; k==0 b = 2; b = 1; b = 2; i < n s = s + a*b; return s; iii+1; = i+1; Saman Amarasinghe 12 6.035 ©MIT Fall 2006 s = 0; s=0; a = 4; a = 4; i = 0; k==0 i = 0; k==0 b = 2; b = 1; b = 2; i < n i < n s = s + a*b; return s; iii+1; = i+1; Saman Amarasinghe 13 6.035 ©MIT Fall 2006 s = 0; s=0; a = 4; a = 4; i = 0; k==0 i = 0; k==0 b = 2; b = 1; b = 2; i < n i < n s = s + a*b; s = s + a*b; return s; iii+1; = i+1; Saman Amarasinghe 14 6.035 ©MIT Fall 2006 s = 0; s=0; a = 4; a = 4; i = 0; k==0 i = 0; k==0 b = 2; b = 1; b = 2; i < n i < n s = s + a*b; s = s + a*b; return s; i = i + 1; i = i + 1; Saman Amarasinghe 15 6.035 ©MIT Fall 2006 s = 0; s=0; a = 4; a = 4; i = 0; k==0 i = 0; k==0 b = 2; b = 1; b = 2; i < n i < n s = s + a*b; s = s + a*b; return s; i = i + 1; iii+1; = i+1; Saman Amarasinghe 16 6.035 ©MIT Fall 2006 s = 0; s=0; a = 4; a = 4; i = 0; k==0 i = 0; k==0 b = 2; b = 1; b = 2; i < n i < n s = s + a*b; s = s + a*b; return s; return s; i = i + 1; iii+1; = i+1; Saman Amarasinghe 17 6.035 ©MIT Fall 2006 s = 0; s=0; a = 4; a = 4; i = 0; k==0 i = 0; k==0 b = 2; b = 1; b = 2; b = 1; i < n i < n s = s + a*b; s = s + a*b; return s; return s; i = i + 1; iii+1; = i+1; Saman Amarasinghe 18 6.035 ©MIT Fall 2006 s = 0; s=0; a = 4; a = 4; i = 0; k==0 i = 0; k==0 b = 2; b = 1; b = 2; b = 1; i < n i < n s = s + a*b; s = s + a*b; return s; return s; i = i + 1; iii+1; = i+1; Saman Amarasinghe 19 6.035 ©MIT Fall 2006 s = 0; s=0; a = 4; a = 4; i = 0; k==0 i = 0; k==0 b = 2; b = 1; b = 2; b = 1; i < n i < n s = s + a*b; s = s + a*b; return s; return s; i = i + 1; iii+1; = i+1; Saman Amarasinghe 20 6.035 ©MIT Fall 2006 Program Points, Split and Join Points • One program point before and after each statement in program • Split point has multiple successors – conditional branch statements only split points • Merge point has multiple predecessors • Each basic block – Either starts with a merge point or its predecessor ends with a split point – Either ends with a split point or its successor stttarts wiithth a merge point Saman Amarasinghe 21 6.035 ©MIT Fall 1998 Basic Block Optimizations • Common SSubub - • Copy Propagation Expression Elimination – a=x+y; b=a; c=b+z; –a=(x+y) y)+z; b=x+y; – a=x+y; b=a; c=a+z; – t=x+y; a=t+z; b=t; • Constant Pr opagation • Dead Code Elimination –x=5; b=x+y; – a=x+y; b=a; b=a+z; –x=5; b=5+y; y; – a=x+y; b=a+z • Algebraic Identities • Strength Reduction – a=x*1; – tit=i*4*4; –a=x; – t=i<<2; Saman Amarasinghe 22 6.035 ©MIT Fall 1998 Basic Block Analysis App pproach • Assume normalized basic block - all statements are of the form – var = var op var (where op is a binary operator) – var = op var (where op is a unary operator) – var = var • Simulate a symbolic execution of basic block – Reason about values of variables (or other aspects of computation) – Derive property of interest Saman Amarasinghe 23 6.035 ©MIT Fall 1998 Two Kinds of Variables • Temp oraries Introduced By Comp iler – Transfer values only within basic block –Introduced as papa rt of instruction flattening – Introduced by optimizations/transformations – Typically assigned to only once • Program Variables – Declared in original program – May be assigned to multiple times – May t rans fer va lues between basic blbl ock s Saman Amarasinghe 24 6.035 ©MIT Fall 1998 Outline • Introduction • Basic Blocks • Common Subexpression Elimination • Copy P ropa gatition •Dead CCodeode Eliminatation • Algebraic Simplification • Summary Value Numbering • Reason about values of variables and expressions in the program – SimulateSimulate executionexecution ofof basicbasic blockblock – Assign virtual value to each variable and expression • Discovered pproperty:roperty: which vvariablesariables and eexpressionsxpressions have the same value • Standarduse: – Common subexpression elimination – Typically combined with transformation that • Saves computed values in temporaries • Replaces expressions with temporaries when value of expression previously computed Saman Amarasinghe 26 6.035 ©MIT Fall 1998 New Basic Original Basic Block Block a = x+y a = x+y t1 = a b = aaz+z b=b = a+za+z b = b+y t2 = b c = a+z b = b+y t3 = b Var to Val c = t2 x v1 y v2 Exp to Val Exp to Tmp a v3 v1+v2 v3 v1+v2 t1 z v4 v3+v4 v5 v3+v4 t2 b v5v6 v5+v2 t6 c v5 v5+v2 v6 Saman Amarasinghe 27 6.035 ©MIT Fall 1998 Value Numbering Summary • Forward symbolic execution of basic block • Each new value assigned to temporary – a=x+y; becomes a=x+y; t=a; – Temporary ppreservesreserves value fforor use llaterater in program eevenven if original variable rewritten • a=x+y; a=a+z; b=x+y becomes • a=x+y; t=a; a=a+z; b=t; • Maps – VtVar to Val – specifies symbolic value for eachvar iable – Exp to Val – specifies value of each evaluated expression – Exp toto TmpTmp – specifies tmp tthathat hholdsolds value ofof eacheach evaluated expression Saman Amarasinghe 28 6.035 ©MIT Fall 1998 Map Usage •Var to Val – Used to compute symbolic value of y and z when processing statement offf form x = y + z •Exp to Tmp – Used to determine which tmp to use if value(y) + value(z) previously computed when processing statement ooff fformorm x = y + z •Exp to Val – Used to update Var to Val when • processing statement of the form x = y + z, and • value(y) + value(z)value(z) previouslypreviously computedcomputed Saman Amarasinghe 29 6.035 ©MIT Fall 1998 Interesting Properties • Finds common subexpressions even if they use diff erent vari ables in expressions – y=a+b; x=b; z=a+x becomes – y= aa+b;+b;t t= y;y; x= b;b;z z= t – Why? Because computes with symbolic values • Finds ccommonommon subexpressions eveneven iiff vvariableariable that originally held the value was overwritten – yya=a+b;+b; y1y=1;; zaz =a+b+b becomes – y=a+b; t=y; y=1; z=t –Why ? Because saves values away in temporaries Saman Amarasinghe 30 6.035 ©MIT Fall 1998 One More Interesting Property • Flattening and CSE combine to capture partial and arbitrarily complex common subexpressions w=(a+b)+c; y=(a+x)+c; z=a+b; – After flattening: t1=a+b; wtw=t1+c;1+c; xbx=b;; t2 =a+x; yty=t2+c;2+c; z =aa+b;+b; x=b; – CSE algorithm notices that •t1+c andt 2+c compute same value • In the statement z = a+b, a+b has already been computed so generated code can reuse the result t1=a+b; w=t1+c; t3=w; x=b; t2=t1; y=t3; z=t1; Saman Amarasinghe 31 6.035 ©MIT Fall 1998 Problems I • Algorithm has a temporary for each new value – a=x+y; t1=a; •Introduces – lots of temporaries – lots of copy statements to temporaries • In many cases, temporaries and copy statements are unnecessary • S o we ellii mina te ththem withith copy propagation and dead code elimination Saman Amarasinghe 32 6.035 ©MIT Fall 1998 Problems II • Expressions have to be identical –
Recommended publications
  • A Methodology for Assessing Javascript Software Protections

    A Methodology for Assessing Javascript Software Protections

    A methodology for Assessing JavaScript Software Protections Pedro Fortuna A methodology for Assessing JavaScript Software Protections Pedro Fortuna About me Pedro Fortuna Co-Founder & CTO @ JSCRAMBLER OWASP Member SECURITY, JAVASCRIPT @pedrofortuna 2 A methodology for Assessing JavaScript Software Protections Pedro Fortuna Agenda 1 4 7 What is Code Protection? Testing Resilience 2 5 Code Obfuscation Metrics Conclusions 3 6 JS Software Protections Q & A Checklist 3 What is Code Protection Part 1 A methodology for Assessing JavaScript Software Protections Pedro Fortuna Intellectual Property Protection Legal or Technical Protection? Alice Bob Software Developer Reverse Engineer Sells her software over the Internet Wants algorithms and data structures Does not need to revert back to original source code 5 A methodology for Assessing JavaScript Software Protections Pedro Fortuna Intellectual Property IP Protection Protection Legal Technical Encryption ? Trusted Computing Server-Side Execution Obfuscation 6 A methodology for Assessing JavaScript Software Protections Pedro Fortuna Code Obfuscation Obfuscation “transforms a program into a form that is more difficult for an adversary to understand or change than the original code” [1] More Difficult “requires more human time, more money, or more computing power to analyze than the original program.” [1] in Collberg, C., and Nagra, J., “Surreptitious software: obfuscation, watermarking, and tamperproofing for software protection.”, Addison- Wesley Professional, 2010. 7 A methodology for Assessing
  • Attacking Client-Side JIT Compilers.Key

    Attacking Client-Side JIT Compilers.Key

    Attacking Client-Side JIT Compilers Samuel Groß (@5aelo) !1 A JavaScript Engine Parser JIT Compiler Interpreter Runtime Garbage Collector !2 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !3 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !4 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !5 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !6 Agenda 1. Background: Runtime Parser • Object representation and Builtins JIT Compiler 2. JIT Compiler Internals • Problem: missing type information • Solution: "speculative" JIT Interpreter 3.
  • CS153: Compilers Lecture 19: Optimization

    CS153: Compilers Lecture 19: Optimization

    CS153: Compilers Lecture 19: Optimization Stephen Chong https://www.seas.harvard.edu/courses/cs153 Contains content from lecture notes by Steve Zdancewic and Greg Morrisett Announcements •HW5: Oat v.2 out •Due in 2 weeks •HW6 will be released next week •Implementing optimizations! (and more) Stephen Chong, Harvard University 2 Today •Optimizations •Safety •Constant folding •Algebraic simplification • Strength reduction •Constant propagation •Copy propagation •Dead code elimination •Inlining and specialization • Recursive function inlining •Tail call elimination •Common subexpression elimination Stephen Chong, Harvard University 3 Optimizations •The code generated by our OAT compiler so far is pretty inefficient. •Lots of redundant moves. •Lots of unnecessary arithmetic instructions. •Consider this OAT program: int foo(int w) { var x = 3 + 5; var y = x * w; var z = y - 0; return z * 4; } Stephen Chong, Harvard University 4 Unoptimized vs. Optimized Output .globl _foo _foo: •Hand optimized code: pushl %ebp movl %esp, %ebp _foo: subl $64, %esp shlq $5, %rdi __fresh2: movq %rdi, %rax leal -64(%ebp), %eax ret movl %eax, -48(%ebp) movl 8(%ebp), %eax •Function foo may be movl %eax, %ecx movl -48(%ebp), %eax inlined by the compiler, movl %ecx, (%eax) movl $3, %eax so it can be implemented movl %eax, -44(%ebp) movl $5, %eax by just one instruction! movl %eax, %ecx addl %ecx, -44(%ebp) leal -60(%ebp), %eax movl %eax, -40(%ebp) movl -44(%ebp), %eax Stephen Chong,movl Harvard %eax,University %ecx 5 Why do we need optimizations? •To help programmers… •They write modular, clean, high-level programs •Compiler generates efficient, high-performance assembly •Programmers don’t write optimal code •High-level languages make avoiding redundant computation inconvenient or impossible •e.g.
  • Quaxe, Infinity and Beyond

    Quaxe, Infinity and Beyond

    Quaxe, infinity and beyond Daniel Glazman — WWX 2015 /usr/bin/whoami Primary architect and developer of the leading Web and Ebook editors Nvu and BlueGriffon Former member of the Netscape CSS and Editor engineering teams Involved in Internet and Web Standards since 1990 Currently co-chair of CSS Working Group at W3C New-comer in the Haxe ecosystem Desktop Frameworks Visual Studio (Windows only) Xcode (OS X only) Qt wxWidgets XUL Adobe Air Mobile Frameworks Adobe PhoneGap/Air Xcode (iOS only) Qt Mobile AppCelerator Visual Studio Two solutions but many issues Fragmentation desktop/mobile Heavy runtimes Can’t easily reuse existing c++ libraries Complex to have native-like UI Qt/QtMobile still require c++ Qt’s QML is a weak and convoluted UI language Haxe 9 years success of Multiplatform OSS language Strong affinity to gaming Wide and vibrant community Some press recognition Dead code elimination Compiles to native on all But no native GUI… platforms through c++ and java Best of all worlds Haxe + Qt/QtMobile Multiplatform Native apps, native performance through c++/Java C++/Java lib reusability Introducing Quaxe Native apps w/o c++ complexity Highly dynamic applications on desktop and mobile Native-like UI through Qt HTML5-based UI, CSS-based styling Benefits from Haxe and Qt communities Going from HTML5 to native GUI completeness DOM dynamism in native UI var b: Element = document.getElementById("thirdButton"); var t: Element = document.createElement("input"); t.setAttribute("type", "text"); t.setAttribute("value", "a text field"); b.parentNode.insertBefore(t,
  • Dead Code Elimination for Web Applications Written in Dynamic Languages

    Dead Code Elimination for Web Applications Written in Dynamic Languages

    Dead code elimination for web applications written in dynamic languages Master’s Thesis Hidde Boomsma Dead code elimination for web applications written in dynamic languages THESIS submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE in COMPUTER ENGINEERING by Hidde Boomsma born in Naarden 1984, the Netherlands Software Engineering Research Group Department of Software Technology Department of Software Engineering Faculty EEMCS, Delft University of Technology Hostnet B.V. Delft, the Netherlands Amsterdam, the Netherlands www.ewi.tudelft.nl www.hostnet.nl © 2012 Hidde Boomsma. All rights reserved Cover picture: Hoster the Hostnet mascot Dead code elimination for web applications written in dynamic languages Author: Hidde Boomsma Student id: 1174371 Email: [email protected] Abstract Dead code is source code that is not necessary for the correct execution of an application. Dead code is a result of software ageing. It is a threat for maintainability and should therefore be removed. Many organizations in the web domain have the problem that their software grows and de- mands increasingly more effort to maintain, test, check out and deploy. Old features often remain in the software, because their dependencies are not obvious from the software documentation. Dead code can be found by collecting the set of code that is used and subtract this set from the set of all code. Collecting the set can be done statically or dynamically. Web applications are often written in dynamic languages. For dynamic languages dynamic analysis suits best. From the maintainability perspective a dynamic analysis is preferred over static analysis because it is able to detect reachable but unused code.
  • Lecture Notes on Peephole Optimizations and Common Subexpression Elimination

    Lecture Notes on Peephole Optimizations and Common Subexpression Elimination

    Lecture Notes on Peephole Optimizations and Common Subexpression Elimination 15-411: Compiler Design Frank Pfenning and Jan Hoffmann Lecture 18 October 31, 2017 1 Introduction In this lecture, we discuss common subexpression elimination and a class of optimiza- tions that is called peephole optimizations. The idea of common subexpression elimination is to avoid to perform the same operation twice by replacing (binary) operations with variables. To ensure that these substitutions are sound we intro- duce dominance, which ensures that substituted variables are always defined. Peephole optimizations are optimizations that are performed locally on a small number of instructions. The name is inspired from the picture that we look at the code through a peephole and make optimization that only involve the small amount code we can see and that are indented of the rest of the program. There is a large number of possible peephole optimizations. The LLVM com- piler implements for example more than 1000 peephole optimizations [LMNR15]. In this lecture, we discuss three important and representative peephole optimiza- tions: constant folding, strength reduction, and null sequences. 2 Constant Folding Optimizations have two components: (1) a condition under which they can be ap- plied and the (2) code transformation itself. The optimization of constant folding is a straightforward example of this. The code transformation itself replaces a binary operation with a single constant, and applies whenever c1 c2 is defined. l : x c1 c2 −! l : x c (where c =
  • Code Optimizations Recap Peephole Optimization

    Code Optimizations Recap Peephole Optimization

    7/23/2016 Program Analysis Recap https://www.cse.iitb.ac.in/~karkare/cs618/ • Optimizations Code Optimizations – To improve efficiency of generated executable (time, space, resources …) Amey Karkare – Maintain semantic equivalence Dept of Computer Science and Engg • Two levels IIT Kanpur – Machine Independent Visiting IIT Bombay [email protected] – Machine Dependent [email protected] 2 Peephole Optimization Peephole optimization examples… • target code often contains redundant Redundant loads and stores instructions and suboptimal constructs • Consider the code sequence • examine a short sequence of target instruction (peephole) and replace by a Move R , a shorter or faster sequence 0 Move a, R0 • peephole is a small moving window on the target systems • Instruction 2 can always be removed if it does not have a label. 3 4 1 7/23/2016 Peephole optimization examples… Unreachable code example … Unreachable code constant propagation • Consider following code sequence if 0 <> 1 goto L2 int debug = 0 print debugging information if (debug) { L2: print debugging info } Evaluate boolean expression. Since if condition is always true the code becomes this may be translated as goto L2 if debug == 1 goto L1 goto L2 print debugging information L1: print debugging info L2: L2: The print statement is now unreachable. Therefore, the code Eliminate jumps becomes if debug != 1 goto L2 print debugging information L2: L2: 5 6 Peephole optimization examples… Peephole optimization examples… • flow of control: replace jump over jumps • Strength reduction
  • Validating Register Allocation and Spilling

    Validating Register Allocation and Spilling

    Validating Register Allocation and Spilling Silvain Rideau1 and Xavier Leroy2 1 Ecole´ Normale Sup´erieure,45 rue d'Ulm, 75005 Paris, France [email protected] 2 INRIA Paris-Rocquencourt, BP 105, 78153 Le Chesnay, France [email protected] Abstract. Following the translation validation approach to high- assurance compilation, we describe a new algorithm for validating a posteriori the results of a run of register allocation. The algorithm is based on backward dataflow inference of equations between variables, registers and stack locations, and can cope with sophisticated forms of spilling and live range splitting, as well as many architectural irregular- ities such as overlapping registers. The soundness of the algorithm was mechanically proved using the Coq proof assistant. 1 Introduction To generate fast and compact machine code, it is crucial to make effective use of the limited number of registers provided by hardware architectures. Register allocation and its accompanying code transformations (spilling, reloading, coa- lescing, live range splitting, rematerialization, etc) therefore play a prominent role in optimizing compilers. As in the case of any advanced compiler pass, mistakes sometimes happen in the design or implementation of register allocators, possibly causing incorrect machine code to be generated from a correct source program. Such compiler- introduced bugs are uncommon but especially difficult to exhibit and track down. In the context of safety-critical software, they can also invalidate all the safety guarantees obtained by formal verification of the source code, which is a growing concern in the formal methods world. There exist two major approaches to rule out incorrect compilations. Com- piler verification proves, once and for all, the correctness of a compiler or compi- lation pass, preferably using mechanical assistance (proof assistants) to conduct the proof.
  • Compiler-Based Code-Improvement Techniques

    Compiler-Based Code-Improvement Techniques

    Compiler-Based Code-Improvement Techniques KEITH D. COOPER, KATHRYN S. MCKINLEY, and LINDA TORCZON Since the earliest days of compilation, code quality has been recognized as an important problem [18]. A rich literature has developed around the issue of improving code quality. This paper surveys one part of that literature: code transformations intended to improve the running time of programs on uniprocessor machines. This paper emphasizes transformations intended to improve code quality rather than analysis methods. We describe analytical techniques and specific data-flow problems to the extent that they are necessary to understand the transformations. Other papers provide excellent summaries of the various sub-fields of program analysis. The paper is structured around a simple taxonomy that classifies transformations based on how they change the code. The taxonomy is populated with example transformations drawn from the literature. Each transformation is described at a depth that facilitates broad understanding; detailed references are provided for deeper study of individual transformations. The taxonomy provides the reader with a framework for thinking about code-improving transformations. It also serves as an organizing principle for the paper. Copyright 1998, all rights reserved. You may copy this article for your personal use in Comp 512. Further reproduction or distribution requires written permission from the authors. 1INTRODUCTION This paper presents an overview of compiler-based methods for improving the run-time behavior of programs — often mislabeled code optimization. These techniques have a long history in the literature. For example, Backus makes it quite clear that code quality was a major concern to the implementors of the first Fortran compilers [18].
  • An Analysis of Executable Size Reduction by LLVM Passes

    An Analysis of Executable Size Reduction by LLVM Passes

    CSIT (June 2019) 7(2):105–110 https://doi.org/10.1007/s40012-019-00248-5 S.I. : VISVESVARAYA An analysis of executable size reduction by LLVM passes 1 1 1 1 Shalini Jain • Utpal Bora • Prateek Kumar • Vaibhav B. Sinha • 2 1 Suresh Purini • Ramakrishna Upadrasta Received: 3 December 2018 / Accepted: 27 May 2019 / Published online: 3 June 2019 Ó CSI Publications 2019 Abstract The formidable increase in the number of individual effects; while also study the effect of their smaller and smarter embedded devices has compelled combinations. Our preliminary study over SPEC CPU 2017 programmers to develop more and more specialized benchmarks gives us an insight into the comparative effect application programs for these systems. These resource of the groups of passes on the executable size. Our work intensive programs that have to be executed on limited has potential to enable the user to tailor a custom series of memory systems make a strong case for compiler opti- passes so as to obtain the desired executable size. mizations that reduce the executable size of programs. Standard compilers (like LLVM) offer an out-of-the-box - Keywords Compilers Á Compiler optimizations Á Code Oz optimization option—just a series of compiler opti- size optimizations mization passes—that is specifically targeted for the reduction of the generated executable size. In this paper, we aim to analyze the effects of optimizations of LLVM 1 Introduction compiler on the reduction of executable size. Specifically, we take the size of the executable as a metric and attempt The ever increasing demand for smart embedded devices to divide the -Oz series into logical groups and study their has lead to the development of more sophisticated appli- cations for these memory constrained devices.
  • Just-In-Time Compilation

    Just-In-Time Compilation

    JUST-IN-TIME COMPILATION PROGRAM ANALYSIS AND OPTIMIZATION – DCC888 Fernando Magno Quintão Pereira [email protected] The material in these slides have been taken mostly from two papers: "Dynamic Elimination of Overflow Tests in a Trace Compiler", and "Just-in- Time Value Specialization" A Toy Example #include <stdio.h> #include <stdlib.h> #include <sys/mman.h> int main(void) { char* program; int (*fnptr)(void); int a; program = mmap(NULL, 1000, PROT_EXEC | PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); program[0] = 0xB8; program[1] = 0x34; 1) What is the program on the program[2] = 0x12; left doing? program[3] = 0; program[4] = 0; 2) What is this API all about? program[5] = 0xC3; fnptr = (int (*)(void)) program; 3) What does this program a = fnptr(); have to do with a just-in- printf("Result = %X\n",a); time compiler? } A Toy Example #include <stdio.h> #include <stdlib.h> #include <sys/mman.h> int main(void) { char* program; int (*fnptr)(void); int a; program = mmap(NULL, 1000, PROT_EXEC | PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); program[0] = 0xB8; program[1] = 0x34; program[2] = 0x12; program[3] = 0; program[4] = 0; program[5] = 0xC3; fnptr = (int (*)(void)) program; a = fnptr(); printf("Result = %X\n",a); } A Toy Example #include <stdio.h> #include <stdlib.h> #include <sys/mman.h> int main(void) { char* program; int (*fnptr)(void); int a; program = mmap(NULL, 1000, PROT_EXEC | PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); program[0] = 0xB8; program[1] = 0x34; program[2] = 0x12; program[3]
  • Formal Languages and Compilers Lecture XI—Principles of Code Optimization

    Formal Languages and Compilers Lecture XI—Principles of Code Optimization

    Formal Languages and Compilers Lecture XI—Principles of Code Optimization Alessandro Artale Free University of Bozen-Bolzano Faculty of Computer Science – POS Building, Room: 2.03 [email protected] http://www.inf.unibz.it/∼artale/ Formal Languages and Compilers — BSc course 2017/18 – First Semester Alessandro Artale Formal Languages and Compilers Lecture XI—Principles of Code Optimization Summary of Lecture XI Code Optimization Basic Blocks and Flow Graphs Sources of Optimization 1 Common Subexpression Elimination 2 Copy Propagation 3 Dead-Code Elimination 4 Constant Folding 5 Loop Optimization Alessandro Artale Formal Languages and Compilers Lecture XI—Principles of Code Optimization Code Optimization: Intro Intermediate Code undergoes various transformations—called Optimizations—to make the resulting code running faster and taking less space. Optimization never guarantees that the resulting code is the best possible. We will consider only Machine-Independent Optimizations—i.e., they don’t take into consideration any property of the target machine. The techniques used are a combination of Control-Flow and Data-Flow analysis. Control-Flow Analysis. Identifies loops in the flow graph of a program since such loops are usually good candidates for improvement. Data-Flow Analysis. Collects information about the way variables are used in a program. Alessandro Artale Formal Languages and Compilers Lecture XI—Principles of Code Optimization Criteria for Code-Improving Transformations The best transformations are those that yield the most benefit for the least effort. 1 A transformation must preserve the meaning of a program. It’s better to miss an opportunity to apply a transformation rather than risk changing what the program does.