DOCSLIB.ORG

Compiler Lectures

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Compiler Lectures Calvin Lin The University of Texas at Austin Interprocedural Analysis Last time – Introduction to alias analysis Today – Interprocedural analysis March 4, 2015 Interprocedural Analysis 1 Motivation Procedural abstraction – Cornerstone of programming – Introduces barriers to analysis Example Example x = 5; void f(int x) foo(p); Does foo() { modify x? y = x+1; if (x) foo(); else bar(); } What is the calling . context of f()? f(0); f(1); March 4, 2015 Interprocedural Analysis 2 CS380 C Compilers 1 Calvin Lin The University of Texas at Austin Function Calls and Pointers Recall – Function calls can affect our points-to sets e.g., p1 = &x; p2 = &p1; ... {(p1x), (p2p1)} foo(); ??? Be conservative – Lose a lot of information March 4, 2015 Interprocedural Analysis 3 Interprocedural Analysis Goal – Avoid making conservative assumptions about the effects of procedures and the state at call sites Terminology int a, e; // Globals void foo(int &b, &c) // Formal parameters { b = c; } main() { int d; // Local variables foo(a, d); // Actual parameters } March 4, 2015 Interprocedural Analysis 4 CS380 C Compilers 2 Calvin Lin The University of Texas at Austin Interprocedural Analysis vs. Interprocedural Optimization Interprocedural analysis – Gather information across multiple procedures (typically across the entire program) – Use this information to improve intra-procedural analyses and optimization (e.g., CSE) Interprocedural optimizations – Optimizations that involve multiple procedures e.g., Inlining, procedure cloning, interprocedural register allocation – Optimizations that use interprocedural analysis March 4, 2015 Interprocedural Analysis 5 Dimensions of Interprocedural Analysis Flow-sensitive vs. flow-insensitive Context-sensitive vs. context-insensitive Path-sensitive vs. path-insensitive March 4, 2015 Interprocedural Analysis 6 CS380 C Compilers 3 Calvin Lin The University of Texas at Austin Flow Sensitivity Flow-sensitive analysis – Computes one answer for every program point – Requires iterative data-flow analysis or similar technique Flow-insensitive analysis – Ignores control flow – Computes one answer for every procedure – Faster but less accurate than flow-sensitive analysis March 4, 2015 Interprocedural Analysis 7 Flow Sensitivity Example Is x constant? Flow-sensitive analysis void f(int x) – Computes an answer at every program { point: x = 4; – x is 4 after the first assignment . – x is 5 after the second assignment x = 5; } Flow-insensitive analysis – Computes one answer for the entire procedure: – x is not constant Where have we seen examples of flow-insensitive analysis? – Address Taken pointer analysis March 4, 2015 Interprocedural Analysis 8 CS380 C Compilers 4 Calvin Lin The University of Texas at Austin Context Sensitivity Context-sensitive analysis – Re-analyzes callee for each caller – Also known as polyvariant analysis Context-insensitive analysis – Perform one analysis independent of callers – Also known as monovariant analysis March 4, 2015 Interprocedural Analysis 9 Context Sensitivity Example Is x constant? Context-sensitive analysis – Computes an answer for every callsite: a = id(4); b = id(5); – x is 4 in the first call 4 5 – x is 5 in the second call id(x) { return x; } Context-insensitive analysis – Computes one answer for all callsites: – x is not constant – Suffers from unrealizable paths: a = id(4); b = id(5); – Can mistakenly conclude that 4,5 4,5 id(4) can return 5 because we id(x) { return x; } merge (smear) information from all callsites March 4, 2015 Interprocedural Analysis 10 CS380 C Compilers 5 Calvin Lin The University of Texas at Austin Path Sensitivity Path-sensitive analysis – Computes one answer for every execution path – Subsumes flow-sensitivity and context-sensitivity – Extremely expensive Path-insensitive – Not path-sensitive March 4, 2015 Interprocedural Analysis 11 Path Sensitivity Example Is x constant? Path-sensitive analysis if (x==0) – Computes an answer for every path: – x is 4 at the end of the left path – x is 5 at the end of the right path x = 4; x = 5; Path-insensitive analysis 4 5 – Computes one answer for all paths: print(x) – x is not constant March 4, 2015 Interprocedural Analysis 12 CS380 C Compilers 6 Calvin Lin The University of Texas at Austin Dimensions of Interprocedural Analysis (cont) Flow-insensitive context-insensitive (FICI) int** foo(int **p, **q) { int **x; p {b, d} x = p; . q {f, g} x = q; x {b, d, f, g} return x; } int main() a b d f g { { , , , } int **a, *b, *d, *f, b {c, e} c, e; d {c, e} a = foo(&b, &f); f {c, e} *a = &c; a = foo(&d, &g); g {c, e} *a = &e; } March 4, 2015 Interprocedural Analysis 13 Dimensions of Interprocedural Analysis (cont) Flow-sensitive context-insensitive (FSCI) int** foo(int **p, **q) { int **x; FICI FSCI p {b, d} p {b, d} x = p; . q {f, g} q {f, g} x = q; x {b, d, f, g} x {b, d} return x; 1 } x2 {f, g} int main() a b d f g a f g { { , , , } 1 { , } int **a, *b, *d, *f, b {c, e} a2 {f, g} c, e; d {c, e} f1 {c} a = foo(&b, &f); f {c, e} g {c} *a = &c; 1 a = foo(&d, &g); g {c, e} f2 {c, e} Weak update *a = &e; g {c, e} } 2 March 4, 2015 Interprocedural Analysis 14 CS380 C Compilers 7 Calvin Lin The University of Texas at Austin Interprocedural Analysis: Supergraphs Compose the CFGs for all procedures via the call graph – Connect call nodes to entry nodes of callees x=3 – Connect return nodes of callees back to calls foo() – Called control-flow supergraph foo(x) y=x+1 . foo(1) Pros return – Simple – Intraprocedural analysis algorithms work unchanged – Reasonably effective March 4, 2015 Interprocedural Analysis 15 Monday’s Example Revisited { foo (int *p) int x, y, a; { int *p; return p; } p = &a; x = 5; Is x constant? foo(&x); – With a supergraph, run our same IDFA y = x + 1; algorithm } – Determine that x = 5 March 4, 2015 Interprocedural Analysis 16 CS380 C Compilers 8 Calvin Lin The University of Texas at Austin Supergraphs (cont) Compose the CFGs for all procedures via the call graph – Connect call nodes to entry nodes of callees x=3 – Connect return nodes of callees back to calls foo() – Called control-flow supergraph foo(x) y=x+1 . foo(1) return Cons – Accuracy? Smears information from different contexts. – Performance? IDFA is O(n4), graphs can be huge – No separate compilation IDFA converges in d+2 iterations, where d is the Number of nested loops [Kam & Ullman ’76]. Graphs will have many cycles (one per callsite) March 4, 2015 Interprocedural Analysis 17 Brute Force: Full Context-Sensitive Interprocedural Analysis Invocation Graph [Emami94] – Use an invocation graph, which distinguishes all calling chains – Re-analyze callee for each distinct calling paths void foo(int b) main Pros { hoo(b); } – Precise void goo(int c) foo goo { hoo(c); } Cons – Exponentially expensive main() – Recursion is tricky { hoo hoo int x, y; foo(x); goo(y); } March 4, 2015 Interprocedural Analysis 18 CS380 C Compilers 9 Calvin Lin The University of Texas at Austin Middle Ground: Use Call Graph and Compute Summaries 1 procedure f() 2 begin Goal f 3 call g() – Represent procedure 4 call g() 3,4 5 5 call h() call relationships 9 6 end g h 7 procedure g() 8 begin 10 9 call h() 20 10 call i() 11 end i j 21 12 procedure h() Definition 13 begin – If program P consists of n procedures: p , . ., p 14 end 1 n 15 procedure i() – Static call graph of P is GP = (N,S,E,r) 16 procedure j() – N = {p , . ., p } 17 begin 1 n 18 end – S = {call-site labels} 19 begin – E N N S 20 call g() 21 call j() – r N is start node 22 end March 4, 2015 Interprocedural Analysis 19 Interprocedural Analysis: Summaries Compute summary information for each procedure – Summarize effect of called procedure for callers – Summarize effect of callers for called procedure Store summaries in database – Use later when optimizing procedures Pros – Concise – Can be fast to compute and use – Separate compilation practical Cons – Imprecise if there’s only have one summary per procedure March 4, 2015 Interprocedural Analysis 20 CS380 C Compilers 10 Calvin Lin The University of Texas at Austin Two Types of Information Track information that flows into a procedure – Sometimes known as propagation problems e.g., What formals are constant? e.g., Which formals are aliased to globals? – Useful for optimizing the body of a procedure proc (x,y) { Track information that flows out of a procedure . } – Sometimes known as side effect problems e.g., Which globals are def’d/used by a procedure? e.g., Which locals are def’d/used by a procedure? e.g., Which actual parameters are def’d by a procedure? – Useful for optimizing the code that calls a procedure March 4, 2015 Interprocedural Analysis 21 Examples Propagation Summaries – May-Alias: The set of formals that may be aliased to globals and to each other – Must-Alias: The set of formals that are definitely aliased to globals and to each other – Constant: The set of formals that have constant value Side-effect Summaries – Mod: The set of variables possibly modified (defined) by a call to a procedure – Ref: The set of variables possibly read by a call to a procedure – Kill: The set of variables that are definitely killed by a procedure (e.g., in the liveness sense) March 4, 2015 Interprocedural Analysis 22 CS380 C Compilers 11 Calvin Lin The University of Texas at Austin Computing Interprocedural Summaries Top-down – Summarize information about the caller (May-Alias, Must-Alias) – Use this information inside the procedure body int a; void foo(int &b, &c){ . } foo(a,a); Bottom-up – Summarize the effects of a call (Mod, Ref, Kill)
Load more

Recommended publications
  • Precise Null Pointer Analysis Through Global Value Numbering
    Precise Null Pointer Analysis Through Global Value Numbering Ankush Das1 and Akash Lal2 1 Carnegie Mellon University, Pittsburgh, PA, USA 2 Microsoft Research, Bangalore, India Abstract. Precise analysis of pointer information plays an important role in many static analysis tools. The precision, however, must be bal- anced against the scalability of the analysis. This paper focusses on improving the precision of standard context and flow insensitive alias analysis algorithms at a low scalability cost. In particular, we present a semantics-preserving program transformation that drastically improves the precision of existing analyses when deciding if a pointer can alias Null. Our program transformation is based on Global Value Number- ing, a scheme inspired from compiler optimization literature. It allows even a flow-insensitive analysis to make use of branch conditions such as checking if a pointer is Null and gain precision. We perform experiments on real-world code and show that the transformation improves precision (in terms of the number of dereferences proved safe) from 86.56% to 98.05%, while incurring a small overhead in the running time. Keywords: Alias Analysis, Global Value Numbering, Static Single As- signment, Null Pointer Analysis 1 Introduction Detecting and eliminating null-pointer exceptions is an important step towards developing reliable systems. Static analysis tools that look for null-pointer ex- ceptions typically employ techniques based on alias analysis to detect possible aliasing between pointers. Two pointer-valued variables are said to alias if they hold the same memory location during runtime. Statically, aliasing can be de- cided in two ways: (a) may-alias [1], where two pointers are said to may-alias if they can point to the same memory location under some possible execution, and (b) must-alias [27], where two pointers are said to must-alias if they always point to the same memory location under all possible executions.
    [Show full text]
  • A Formally-Verified Alias Analysis
    A Formally-Verified Alias Analysis Valentin Robert1;2 and Xavier Leroy1 1 INRIA Paris-Rocquencourt 2 University of California, San Diego [email protected], [email protected] Abstract. This paper reports on the formalization and proof of sound- ness, using the Coq proof assistant, of an alias analysis: a static analysis that approximates the flow of pointer values. The alias analysis con- sidered is of the points-to kind and is intraprocedural, flow-sensitive, field-sensitive, and untyped. Its soundness proof follows the general style of abstract interpretation. The analysis is designed to fit in the Comp- Cert C verified compiler, supporting future aggressive optimizations over memory accesses. 1 Introduction Alias analysis. Most imperative programming languages feature pointers, or object references, as first-class values. With pointers and object references comes the possibility of aliasing: two syntactically-distinct program variables, or two semantically-distinct object fields can contain identical pointers referencing the same shared piece of data. The possibility of aliasing increases the expressiveness of the language, en- abling programmers to implement mutable data structures with sharing; how- ever, it also complicates tremendously formal reasoning about programs, as well as optimizing compilation. In this paper, we focus on optimizing compilation in the presence of pointers and aliasing. Consider, for example, the following C program fragment: ... *p = 1; *q = 2; x = *p + 3; ... Performance would be increased if the compiler propagates the constant 1 stored in p to its use in *p + 3, obtaining ... *p = 1; *q = 2; x = 4; ... This optimization, however, is unsound if p and q can alias.
    [Show full text]
  • Aliases, Intro. to Optimization
    Aliasing Two variables are aliased if they can refer to the same storage location. Possible Sources:pointers, parameter passing, storage overlap... Ex. address of a passed x and y are aliased! Pointer Analysis, Alias Analysis to get less conservative info Needed for correct, aggressive optimization Procedures: terminology a, e global b,c formal arguments d local call site with actual arguments At procedure call, formals bound to actuals, may be aliased Ex. (b,a) , (c, d) Globals, actuals may be modified, used Ex. a, b Call Graphs Determines possible flow of control, interprocedurally G = (N, LE, s) N set of nodes LE set of labelled edges n m s start node Qu: Why need call site labels? Why list? Example Call Graph 1,2 3 4 5 6 7 Interprocedural Dataflow Analysis Based on call graph: forward, backward Gen, Kill: Need to summarize procedures per call Flow sensitive: take procedure's control flow into account Flow insensitive: ignore procedure's control flow Difficulties: Hard, complex Flow sensitive alias analysis intractable Separate compilation? Scale compiler can do both flow sensitive and insensitive Most compilers ultraconservative, or flow insensitive Scalar Replacement of Aggregates Use scalar temporary instead of aggregate variable Compiler may limit optimization to such scalars Can do better register allocation, constant propagation,... Particulary useful when small number of constant values Can use constant propagation, dead code elimination to specialize code Value Numbering of Basic Blocks Eliminates computations whose values are already computed in BB value needn't be constant Method: Value Number Hash Table Global Copy Propagation Given A:=B, replace later uses of A by B, as long as A,B not redefined (with dead code elim) Global Copy Propagation Ex.
    [Show full text]
  • Automatic Parallelization of C by Means of Language Transcription
    Automatic Parallelization of C by Means of Language Transcription Richard L. Kennell Rudolf Eigenmann Purdue University, School of Electrical and Computer Engineering Abstract. The automatic parallelization of C has always been frustrated by pointer arithmetic, irregular control flow and complicated data aggregation. Each of these problems is similar to familiar challenges encountered in the parallelization of more rigidly-structured languages such as FORTRAN. By creating a mapping from one language to the other, we can expose the capabil- ities of existing automatically parallelizing compilers to the C language. In this paper, we describe our approach to mapping applications written in C to a form suitable for the Polaris source-to- source FORTRAN compiler. We also describe the improvements in the compiled applications realized by this second level of transformation and show results for a small application in compar- ison to commercial compilers. 1.0 Introduction Polaris is a automatically parallelizing source-to-source FORTRAN compiler. It accepts FORTRAN77 input and produces a FORTRAN output in a new dialect that supports explicit par- allelism by means of embedded directives such as the OpenMP [Ope97] or Sun FORTRAN Directives [Sun96]. The benefit that Polaris provides is in automating the analysis of the loops and array accesses in the application to determine how they can best be expressed to exploit available parallelism. Since FORTRAN naturally constrains the way in which parallelism exists, the analy- sis is somewhat more straightforward than with other languages. This allows Polaris to perform very complicated interprocedural and global analysis without risk of misinterpretation of pro- grammer intent. Experimental results show that Polaris is able to markedly improve the run-time of applications without additional programmer direction [PVE96, BDE+96].
    [Show full text]
  • Automatic Loop Parallelization Via Compiler Guided Refactoring
    Automatic Loop Parallelization via Compiler Guided Refactoring Per Larsen∗, Razya Ladelskyz, Jacob Lidmany, Sally A. McKeey, Sven Karlsson∗ and Ayal Zaksz ∗DTU Informatics Technical U. Denmark, 2800 Kgs. Lyngby, Denmark Email: fpl,[email protected] y Computer Science Engineering Chalmers U. Technology, 412 96 Gothenburg, Sweden Email: [email protected], [email protected] zIBM Haifa Research Labs Mount Carmel, Haifa, 31905, Israel Email: frazya,[email protected] Abstract—For many parallel applications, performance relies with hand-parallelized and optimized versions using an octo- not on instruction-level parallelism, but on loop-level parallelism. core Intel Xeon 5570 system and a quad-core IBM POWER6 Unfortunately, many modern applications are written in ways SCM system. that obstruct automatic loop parallelization. Since we cannot identify sufficient parallelization opportunities for these codes in Our contributions are as follows. a static, off-line compiler, we developed an interactive compilation • First, we present our interactive compilation system. feedback system that guides the programmer in iteratively • Second, we perform an extensive performance evaluation. modifying application source, thereby improving the compiler’s We use two benchmark kernels, two parallel architectures ability to generate loop-parallel code. We use this compilation system to modify two sequential benchmarks, finding that the and also study the behavior of the benchmarks. code parallelized in this way runs up to 8.3 times faster on an After modification with our compilation system, we find octo-core Intel Xeon 5570 system and up to 12.5 times faster on that the two benchmarks runs up to 6.0 and 8.3 times faster a quad-core IBM POWER6 system.
    [Show full text]
  • A General Compiler Framework for Speculative Optimizations Using Data Speculative Code Motion
    A General Compiler Framework for Speculative Optimizations Using Data Speculative Code Motion Xiaoru Dai, Antonia Zhai, Wei-Chung Hsu, Pen-Chung Yew Department of Computer Science and Engineering University of Minnesota Minneapolis, MN 55455 {dai, zhai, hsu, yew}@cs.umn.edu Abstract obtaining precise data dependence analysis is both difficult and expensive for languages such as C in which Data speculative optimization refers to code dynamic and pointer-based data structures are frequently transformations that allow load and store instructions to used. When the data dependence analysis is unable to be moved across potentially dependent memory show that there is definitely no data dependence between operations. Existing research work on data speculative two memory references, the compiler must assume that optimizations has mainly focused on individual code there is a data dependence between them. It is quite often transformation. The required speculative analysis that that such an assumption is overly conservative. The identifies data speculative optimization opportunities and examples in Figure 1 illustrate how such conservative data the required recovery code generation that guarantees the dependences may affect compiler optimizations. correctness of their execution are handled separately for each optimization. This paper proposes a new compiler S1: = *q while ( p ){ while( p ){ framework to facilitate the design and implementation of S2: *p= b 1 S1: if (p->f==0) S1: if (p->f == 0) general data speculative optimizations such as dead store
    [Show full text]
  • Autotuning for Automatic Parallelization on Heterogeneous Systems
    Autotuning for Automatic Parallelization on Heterogeneous Systems Zur Erlangung des akademischen Grades eines Doktors der Ingenieurwissenschaften von der KIT-Fakultät für Informatik des Karlsruher Instituts für Technologie (KIT) genehmigte Dissertation von Philip Pfaffe ___________________________________________________________________ ___________________________________________________________________ Tag der mündlichen Prüfung: 24.07.2019 1. Referent: Prof. Dr. Walter F. Tichy 2. Referent: Prof. Dr. Michael Philippsen Abstract To meet the surging demand for high-speed computation in an era of stagnat- ing increase in performance per processor, systems designers resort to aggregating many and even heterogeneous processors into single systems. Automatic paral- lelization tools relieve application developers of the tedious and error prone task of programming these heterogeneous systems. For these tools, there are two aspects to maximizing performance: Optimizing the execution on each parallel platform individually, and executing work on the available platforms cooperatively. To date, various approaches exist targeting either aspect. Automatic parallelization for simultaneous cooperative computation with optimized per-platform execution however remains an unsolved problem. This thesis presents the APHES framework to close that gap. The framework com- bines automatic parallelization with a novel technique for input-sensitive online autotuning. Its first component, a parallelizing polyhedral compiler, transforms implicitly data-parallel program parts for multiple platforms. Targeted platforms then automatically cooperate to process the work. During compilation, the code is instrumented to interact with libtuning, our new autotuner and second com- ponent of the framework. Tuning the work distribution and per-platform execu- tion maximizes overall performance. The autotuner enables always-on autotuning through a novel hybrid tuning method, combining a new efficient search technique and model-based prediction.
    [Show full text]
  • Vbcc Compiler System
    vbcc compiler system Volker Barthelmann i Table of Contents 1 General :::::::::::::::::::::::::::::::::::::::::: 1 1.1 Introduction ::::::::::::::::::::::::::::::::::::::::::::::::::: 1 1.2 Legal :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1 1.3 Installation :::::::::::::::::::::::::::::::::::::::::::::::::::: 2 1.3.1 Installing for Unix::::::::::::::::::::::::::::::::::::::::: 3 1.3.2 Installing for DOS/Windows::::::::::::::::::::::::::::::: 3 1.3.3 Installing for AmigaOS :::::::::::::::::::::::::::::::::::: 3 1.4 Tutorial :::::::::::::::::::::::::::::::::::::::::::::::::::::::: 5 2 The Frontend ::::::::::::::::::::::::::::::::::: 7 2.1 Usage :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 7 2.2 Configuration :::::::::::::::::::::::::::::::::::::::::::::::::: 8 3 The Compiler :::::::::::::::::::::::::::::::::: 11 3.1 General Compiler Options::::::::::::::::::::::::::::::::::::: 11 3.2 Errors and Warnings :::::::::::::::::::::::::::::::::::::::::: 15 3.3 Data Types ::::::::::::::::::::::::::::::::::::::::::::::::::: 15 3.4 Optimizations::::::::::::::::::::::::::::::::::::::::::::::::: 16 3.4.1 Register Allocation ::::::::::::::::::::::::::::::::::::::: 18 3.4.2 Flow Optimizations :::::::::::::::::::::::::::::::::::::: 18 3.4.3 Common Subexpression Elimination :::::::::::::::::::::: 19 3.4.4 Copy Propagation :::::::::::::::::::::::::::::::::::::::: 20 3.4.5 Constant Propagation :::::::::::::::::::::::::::::::::::: 20 3.4.6 Dead Code Elimination::::::::::::::::::::::::::::::::::: 21 3.4.7 Loop-Invariant Code Motion
    [Show full text]
  • A Performance-Based Approach to Automatic Parallelization
    A Performance-based Approach to Automatic Parallelization Lecture Notes for ECE 663 Advanced Optimizing Compilers Draft Rudolf Eigenmann School of Electrical and Computer Engineering Purdue University c Rudolf Eigenmann 2 Chapter 1 Motivation and Introduction Slide 2: Optimizing Compilers are in the Center of the (Software) Universe Compilers are the translators between “human and machine”. This interface is one of the more challenging and important issues in all of computer science. Through programming languages, software engineers tell machines what do to. Today’s programming languages are still rather cryptic, borrowing a few words from the English language vocabulary. Perhaps, tomorrow’s languages will be more like natural languages. They may offer higher-level ex- pressions, allowing problems to be specified, rather than coding the detailed problem solution algorithms. Translating these languages onto modern architectures with their low-level ma- chine code languages is already a challenge. As every generation of computer architectures tends to grow in complexity, translating future programming languages onto future machines will be an even grander challenge. In performing such translation, optimization is important. Basic translation is usually inefficient. Performance almost always matters. The are other optimization criteria, as well. Energy efficiency is of increasing importance and is critical for devices that are battery operated. Small code and memory size can be of great value for embedded system. In this course, we will focus mainly on performance. Optimizations for parallel machines are the focus of this course. Today’s CPUs contain multiple cores. They are one of the most important classes of current parallel machines. This was not always so.
    [Show full text]
  • Debloating Software Through Piece-Wise Compilation and Loading
    Debloating Software through Piece-Wise Compilation and Loading Anh Quach Aravind Prakash Binghamton University Binghamton University [email protected] [email protected] Lok Yan Air Force Research Laboratory [email protected] Abstract This extraneous code may contain its own bugs and vulnerabilities and therefore broadens the overall attack Programs are bloated. Our study shows that only 5% of surface. Additionally, these features add unnecessary libc is used on average across the Ubuntu Desktop envi- burden on modern defenses (e.g., CFI) that do not dis- ronment (2016 programs); the heaviest user, vlc media tinguish between used and unused features in software. player, only needed 18%. Accumulation of unnecessary code in a binary – either In this paper: (1) We present a debloating framework by design (e.g., shared libraries) or due to software devel- built on a compiler toolchain that can successfully de- opment inefficiencies – amounts to code bloating. As a bloat programs (shared/static libraries and executables). typical example, shared libraries are designed to contain Our solution can successfully compile and load most li- the union of all functionality required by its users. braries on Ubuntu Desktop 16.04. (2) We demonstrate Static dead-code-elimination – a static analysis tech- the elimination of over 79% of code from coreutils nique used to identify unused code paths and remove and 86% of code from SPEC CPU 2006 benchmark pro- them from the final binary – employed during compila- grams without affecting functionality. We show that even tion is an effective means to reduce bloat. In fact, under complex programs such as Firefox and curl can be higher levels of optimization, modern compilers (clang, debloated without a need to recompile.
    [Show full text]
  • Alias Analysis for Optimization of Dynamic Languages ∗
    Alias Analysis for Optimization of Dynamic Languages ∗ MichaelGorbovitski YanhongA.Liu ScottD.Stoller TomRothamel K. Tuncay Tekle Computer Science Dept., State Univ. of New York at Stony Brook, Stony Brook, NY 11794 {mickg,liu,stoller,rothamel,tuncay}@cs.sunysb.edu Abstract 1. Introduction Dynamic languages such as Python allow programs to be Dynamic languages such as Python and JavaScript allow written more easily using high-level constructs such as com- programs to be written more easily using high-level con- prehensions for queries and using generic code. Efficient ex- structs such as comprehensionsfor queries and using generic ecution of programs then requires powerful optimizations— code. Efficient execution of programs then requires power- incrementalization of expensive queries and specialization ful optimizations—incrementalization of expensive queries of generic code. Effective incrementalization and specializa- under updates to query parameters (Liu et al. 2005) and spe- tion of dynamic languages require precise and scalable alias cialization of generic code in procedures and methods under analysis. specific calls to the procedures and methods (Rigo 2004). This paper describes the development and experimental These optimizations require identifying values of variables evaluation of a may-alias analysis for a full dynamic object- and fields that are references to the same object, either a data oriented language, for program optimization by incremen- object or a function object. Due to extensive use of object talization and specialization. The analysis is flow-sensitive; references, effective optimizations require precise and scal- we show that this is necessary for effective optimization of able alias analysis. dynamic languages. It uses precise type analysis and a pow- Alias analysis aims to compute pairs of variables and erful form of context sensitivity, called trace sensitivity, to fields that are aliases of each other, i.e., that refer to the further improve analysis precision.
    [Show full text]
  • Probabilistic Alias Analysis for Parallel Programming in SSA Forms.Pdf
    Probabilistic Alias Analysis for Parallel Programming in SSA Forms Mohamed A. El-Zawawy1 and Mohammad N. Alanazi2 1;2College of Computer and Information Sciences, Al Imam Mohammad Ibn Saud Islamic University (IMSIU) Riyadh, Kingdom of Saudi Arabia 1Department of Mathematics, Faculty of Science Cairo University Giza 12613, Egypt Email1: [email protected] Email2: [email protected] Abstract— Static alias analysis of different type of pro- to achieve tasks like code specialization and data specula- gramming languages has been drawing researcher attention. tion. In other words information calculated by most alias However most of the results of existing techniques for alias analysis techniques do not help compilers to do aggressive analysis are not precise enough compared to needs of optimizations. More specifically, possibly-alias relationships modern compilers. Probabilistic versions of these results, is not rich enough to inform the comfier about the possibility in which result elements are associated with occurrence that constraints for the executions. Hence compilers are probabilities, are required in optimizations techniques of somehow forced to follow a conservative way and assume modern compilers. the conditions validity for all execution paths [1], [2], [3]. This paper presents a new probabilistic approach for alias A dominant programming technique of parallelism for analysis of parallel programs. The treated parallelism model large-scale machines equipped with distributed-memories is that of SPMD where in SPMD, a program is executed is the single program, multiple data (SPMD) model. In using a fixed number of program threads running on dis- SPMD, a program is executed using a fixed number of tributed machines on different data.
    [Show full text]