DOCSLIB.ORG

1 Lecture 20 Pointer Analysis

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
1 Lecture 20 Pointer Analysis Pros and Cons of Pointers • Many procedural languages have pointers Lecture 20 – e.g., C or C++: int *p = &x; • Pointers are powerful and convenient Pointer Analysis – can build arbitrary data structures • Pointers can also hinder compiler optimization – hard to know where pointers are pointing • Basics – must be conservative in their presence • Design Options • Has inspired much research • Pointer Analysis Algorithms – analyses to decide where pointers are pointing – many options and trade-offs • Pointer Analysis Using BDDs – open problem: a scalable accurate analysis • Probabilistic Pointer Analysis (Slide content courtesy of Greg Steffan, U. of Toronto) Carnegie Mellon Carnegie Mellon Todd C. Mowry 15-745: Pointer Analysis 1 15-745: Pointer Analysis 2 Todd C. Mowry Pointer Analysis Basics: Aliases The Pointer Alias Analysis Problem • Two variables are aliases if: • Decide for every pair of pointers at every program point: – they reference the same memory location – do they point to the same memory location? • More useful: • A difficult problem – prove variables reference different locations – shown to be undecidable by Landi, 1992 • Correctness: Alias sets: – report all pairs of pointers which do/may alias • Ambiguous: – int x,y; two pointers which may or may not alias • Accuracy/Precision: int *p = &x; – how few pairs of pointers are reported while remaining correct int *q = &y; – ie., reduce ambiguity to improve accuracy int *r = p; int **s = &q; Carnegie Mellon Carnegie Mellon 15-745: Pointer Analysis 3 Todd C. Mowry 15-745: Pointer Analysis 4 Todd C. Mowry 1 Many Uses of Pointer Analysis Challenges for Pointer Analysis • Basic compiler optimizations • Complexity: huge in space and time – register allocation, CSE, dead code elimination, live variables, – compare every pointer with every other pointer instruction scheduling, loop invariant code motion, redundant load/ – at every program point store elimination – potentially considering all program paths to that point • Parallelization • Scalability vs accuracy trade-off – instruction-level parallelism – different analyses motivated for different purposes – thread-level parallelism – many useful algorithms (adds to confusion) • Behavioral synthesis • Coding corner cases – automatically converting C-code into gates – pointer arithmetic (*p++), casting, function pointers, long-jumps • Error detection and program understanding • Whole program? – memory leaks, wild pointers, security holes – most algorithms require the entire program – library code? optimizing at link-time only? Carnegie Mellon Carnegie Mellon 15-745: Pointer Analysis 5 Todd C. Mowry 15-745: Pointer Analysis 6 Todd C. Mowry Pointer Analysis: Design Options Representation • Representation • Track pointer aliases • Heap modeling – <*a, b>, <*a, e>, <b, e>, • Aggregate modeling <**a, c>, <**a, d>, … • Flow sensitivity – More precise, less efficient • Context sensitivity • Track points-to information – <a, b>, <b, c>, <b, d>, <e, c>, <e, d> – Less precise, more efficient a = &b; b = &c; b = &d; e = b; Carnegie Mellon Carnegie Mellon 15-745: Pointer Analysis 7 Todd C. Mowry 15-745: Pointer Analysis 8 Todd C. Mowry 2 Heap Modeling Options Aggregate Modeling Options • Heap merged Arrays Structures – i.e. “no heap modeling” • Allocation site (any call to malloc/calloc) Elements are treated Elements are treated – … Consider each to be a unique location as individual locations as individual locations – Doesn’t differentiate between multiple objects allocated by the … (“field sensitive”) same allocation site or • Shape analysis Treat entire array – Recognize linked lists, trees, DAGs, etc. as a single location or or … Treat first element Treat entire structure separate from others as a single location Carnegie Mellon Carnegie Mellon 15-745: Pointer Analysis 9 Todd C. Mowry 15-745: Pointer Analysis 10 Todd C. Mowry Flow Sensitivity Options Flow Sensitivity Example • Flow insensitive (assuming allocation-site heap modeling) – The order of statements doesn’t matter Flow Insensitive • Result of analysis is the same regardless of statement order aS7 à – Uses a single global state to store results as they are computed S1: a = malloc(…); – Not very accurate S2: b = malloc(…); • Flow sensitive S3: a = b; S4: a = malloc(…); – The order of the statements matter Flow Sensitive S5: if(c) à – Need a control flow graph a = b; aS7 – Must store results for each program point S6: if(!c) – Improves accuracy a = malloc(…); • S7: … = *a; Path sensitive Path Sensitive – Each path in a control flow graph is considered aS7 à Carnegie Mellon Carnegie Mellon 15-745: Pointer Analysis 11 Todd C. Mowry 15-745: Pointer Analysis 12 Todd C. Mowry 3 Context Sensitivity Options Pointer Alias Analysis Algorithms • Context insensitive/sensitive References: – whether to consider different calling contexts • “Points-to analysis in almost linear time”, Steensgaard, POPL 1996 – e.g., what are the possibilities for p at S6? • “Program Analysis and Specialization for the C Programming Language”, Andersen, Technical Report, 1994 int f() Context Insensitive: • “Context-sensitive interprocedural points-to analysis in the presence of { function pointers”, Emami et al., PLDI 1994 S4: p = &b; int a, b, *p; • “Pointer analysis: haven't we solved this problem yet?”, Hind, PASTE S5: g(); int main() 2001 } { • “Which pointer analysis should I use?”, Hind et al., ISSTA 2000 S1: f(); S2: p = &a; Context Sensitive: S3: g(); } int g() { S6: … = *p; } Carnegie Mellon Carnegie Mellon 15-745: Pointer Analysis 13 Todd C. Mowry 15-745: Pointer Analysis 14 Todd C. Mowry Address Taken Address Taken Example • Basic, fast, ultra-conservative algorithm T *p, *q, *r; – flow-insensitive, context-insensitive – often used in production compilers int main() { void f() { g(T **fp) { S1: p = alloc(T); S6: q = alloc(T); T local; • Algorithm: if(…) f(); g(&q); – Generate the set of all variables whose addresses are assigned to s9: p = &local; g(&p); S8: r = alloc(T); another variable. } S4: p = alloc(T); } – Assume that any pointer can potentially point to any variable in that S5: … = *p; set. } • Complexity: O(n) - linear in size of program • Accuracy: very imprecise pS5 = Carnegie Mellon Carnegie Mellon 15-745: Pointer Analysis 15 Todd C. Mowry 15-745: Pointer Analysis 16 Todd C. Mowry 4 Andersen’s Algorithm Andersen Example • Flow-insensitive, context-insensitive, iterative T *p, *q, *r; • Representation: – one points-to graph for entire program int main() { void f() { g(T **fp) { S1: p = alloc(T); S6: q = alloc(T); T local; – each node represents exactly one location if(…) f(); g(&q); • For each statement, build the points-to graph: s9: p = &local; g(&p); S8: r = alloc(T); } y = &x y points-to x S4: p = alloc(T); } S5: … = *p; y = x if x points-to w } then y points-to w *y = x if y points-to z and x points-to w then z points-to w y = *x if x points-to z and z points-to w then y points-to w p = • Iterate until graph no longer changes S5 • Worst case complexity: O(n3), where n = program size Carnegie Mellon Carnegie Mellon 15-745: Pointer Analysis 17 Todd C. Mowry 15-745: Pointer Analysis 18 Todd C. Mowry Steensgaard’s Algorithm Steensgaard Example • Flow-insensitive, context-insensitive T *p, *q, *r; • Representation: – a compact points-to graph for entire program int main() { void f() { g(T **fp) { T local; • each node can represent multiple locations S1: p = alloc(T); S6: q = alloc(T); if(…) f(); g(&q); • but can only point to one other node s9: p = &local; g(&p); S8: r = alloc(T); – i.e. every node has a fan-out of 1 or 0 } S4: p = alloc(T); • union-find data structure implements fan-out } S5: … = *p; – “unioning” while finding eliminates need to iterate } • Worst case complexity: O(n) • Precision: less precise than Andersen’s pS5 = Carnegie Mellon Carnegie Mellon 15-745: Pointer Analysis 19 Todd C. Mowry 15-745: Pointer Analysis 20 Todd C. Mowry 5 Example with Flow Sensitivity Pointer Analysis Using BDDs T *p, *q, *r; References: • “Cloning-based context-sensitive pointer alias analysis using binary int main() { void f() { g(T **fp) { decision diagrams”, Whaley and Lam, PLDI 2004 S1: p = alloc(T); S6: q = alloc(T); T local; • “Symbolic pointer analysis revisited”, Zhu and Calman, PDLI 2004 if(…) f(); g(&q); s9: p = &local; • “Points-to analysis using BDDs”, Berndl et al, PDLI 2003 g(&p); S8: r = alloc(T); } S4: p = alloc(T); } S5: … = *p; } pS5 = pS9 = Carnegie Mellon Carnegie Mellon 15-745: Pointer Analysis 21 Todd C. Mowry 15-745: Pointer Analysis 22 Todd C. Mowry Binary Decision Diagram (BDD) BDD-Based Pointer Analysis • Use a BDD to represent transfer functions – encode procedure as a function of its calling context – compact and efficient representation • Perform context-sensitive, inter-procedural analysis – similar to dataflow analysis – but across the procedure call graph • Gives accurate results – and scales up to large programs Binary Decision Tree Truth Table BDD Carnegie Mellon Carnegie Mellon 15-745: Pointer Analysis 23 Todd C. Mowry 15-745: Pointer Analysis 24 Todd C. Mowry 6 Probabilistic Pointer Analysis Pointer Analysis: Yes, No, & Maybe References: • “A Probabilistic Pointer Analysis for Speculative Optimizations”, DaSilva and Steffan, ASPLOS 2006 *a = ~ optimize • “Compiler support for speculative multithreading architecture with ~ = *b probabilistic points-to analysis”, Shen et al., PPoPP 2003 Pointer Definitely • “Speculative Alias Analysis for Executable Code”, Fernandez and Analysis Definitely Not Espasa, PACT 2002 • “A General Compiler Framework for Speculative
Load more

Recommended publications
  • Expression Rematerialization for VLIW DSP Processors with Distributed Register Files ?
    Expression Rematerialization for VLIW DSP Processors with Distributed Register Files ? Chung-Ju Wu, Chia-Han Lu, and Jenq-Kuen Lee Department of Computer Science, National Tsing-Hua University, Hsinchu 30013, Taiwan {jasonwu,chlu}@pllab.cs.nthu.edu.tw,[email protected] Abstract. Spill code is the overhead of memory load/store behavior if the available registers are not sufficient to map live ranges during the process of register allocation. Previously, works have been proposed to reduce spill code for the unified register file. For reducing power and cost in design of VLIW DSP processors, distributed register files and multi- bank register architectures are being adopted to eliminate the amount of read/write ports between functional units and registers. This presents new challenges for devising compiler optimization schemes for such ar- chitectures. This paper aims at addressing the issues of reducing spill code via rematerialization for a VLIW DSP processor with distributed register files. Rematerialization is a strategy for register allocator to de- termine if it is cheaper to recompute the value than to use memory load/store. In the paper, we propose a solution to exploit the character- istics of distributed register files where there is the chance to balance or split live ranges. By heuristically estimating register pressure for each register file, we are going to treat them as optional spilled locations rather than spilling to memory. The choice of spilled location might pre- serve an expression result and keep the value alive in different register file. It increases the possibility to do expression rematerialization which is effectively able to reduce spill code.
    [Show full text]
  • Equality Saturation: a New Approach to Optimization
    Logical Methods in Computer Science Vol. 7 (1:10) 2011, pp. 1–37 Submitted Oct. 12, 2009 www.lmcs-online.org Published Mar. 28, 2011 EQUALITY SATURATION: A NEW APPROACH TO OPTIMIZATION ROSS TATE, MICHAEL STEPP, ZACHARY TATLOCK, AND SORIN LERNER Department of Computer Science and Engineering, University of California, San Diego e-mail address: {rtate,mstepp,ztatlock,lerner}@cs.ucsd.edu Abstract. Optimizations in a traditional compiler are applied sequentially, with each optimization destructively modifying the program to produce a transformed program that is then passed to the next optimization. We present a new approach for structuring the optimization phase of a compiler. In our approach, optimizations take the form of equality analyses that add equality information to a common intermediate representation. The op- timizer works by repeatedly applying these analyses to infer equivalences between program fragments, thus saturating the intermediate representation with equalities. Once saturated, the intermediate representation encodes multiple optimized versions of the input program. At this point, a profitability heuristic picks the final optimized program from the various programs represented in the saturated representation. Our proposed way of structuring optimizers has a variety of benefits over previous approaches: our approach obviates the need to worry about optimization ordering, enables the use of a global optimization heuris- tic that selects among fully optimized programs, and can be used to perform translation validation, even on compilers other than our own. We present our approach, formalize it, and describe our choice of intermediate representation. We also present experimental results showing that our approach is practical in terms of time and space overhead, is effective at discovering intricate optimization opportunities, and is effective at performing translation validation for a realistic optimizer.
    [Show full text]
  • 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]
  • Practical and Accurate Low-Level Pointer Analysis
    Practical and Accurate Low-Level Pointer Analysis Bolei Guo Matthew J. Bridges Spyridon Triantafyllis Guilherme Ottoni Easwaran Raman David I. August Department of Computer Science, Princeton University {bguo, mbridges, strianta, ottoni, eraman, august}@princeton.edu Abstract High−Level IR Low−Level IR Pointer SuperBlock .... Inlining Opti Scheduling .... Analysis Formation Pointer analysis is traditionally performed once, early Source Machine Code Code in the compilation process, upon an intermediate repre- Lowering sentation (IR) with source-code semantics. However, per- forming pointer analysis only once at this level imposes a Figure 1. Traditional compiler organization phase-ordering constraint, causing alias information to be- char A[10],B[10],C[10]; . come stale after subsequent code transformations. More- foo() { int i; over, high-level pointer analysis cannot be used at link time char *p; or run time, where the source code is unavailable. for (i=0;i<10;i++) { if (...) 1: p = A 2: p = B 1: p = A 2: p = B This paper advocates performing pointer analysis on a 1: p = A; 3': C[i] = p[i] 3: C[i] = p[i] else low-level intermediate representation. We present the first 2: p = B; 4': A[i] = ... 4: A[i] = ... 3: C[i] = p[i]; context-sensitive and partially flow-sensitive points-to anal- 4: A[i] = ...; 3: C[i] = p[i] } 4: A[i] = ... ysis designed to operate at the assembly level. As we will } demonstrate, low-level pointer analysis can be as accurate (a) Source code (b) Source code CFG (c) Transformed code CFG as high-level analysis. Additionally, our low-level pointer analysis also enables a quantitative comparison of prop- agating high-level pointer analysis results through subse- Figure 2.
    [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]
  • Dead Code Elimination Based Pointer Analysis for Multithreaded Programs
    Journal of the Egyptian Mathematical Society (2012) 20, 28–37 Egyptian Mathematical Society Journal of the Egyptian Mathematical Society www.etms-eg.org www.elsevier.com/locate/joems ORIGINAL ARTICLE Dead code elimination based pointer analysis for multithreaded programs Mohamed A. El-Zawawy Department of Mathematics, Faculty of Science, Cairo University, Giza 12316, Egypt Available online 2 February 2012 Abstract This paper presents a new approach for optimizing multitheaded programs with pointer constructs. The approach has applications in the area of certified code (proof-carrying code) where a justification or a proof for the correctness of each optimization is required. The optimization meant here is that of dead code elimination. Towards optimizing multithreaded programs the paper presents a new operational semantics for parallel constructs like join-fork constructs, parallel loops, and conditionally spawned threads. The paper also presents a novel type system for flow-sensitive pointer analysis of multithreaded pro- grams. This type system is extended to obtain a new type system for live-variables analysis of mul- tithreaded programs. The live-variables type system is extended to build the third novel type system, proposed in this paper, which carries the optimization of dead code elimination. The justification mentioned above takes the form of type derivation in our approach. ª 2011 Egyptian Mathematical Society. Production and hosting by Elsevier B.V. All rights reserved. 1. Introduction (a) concealing suspension caused by some commands, (b) mak- ing it easier to build huge software systems, (c) improving exe- One of the mainstream programming approaches today is mul- cution of programs specially those that are executed on tithreading.
    [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]
  • Topic 1D Slides
    Topic I (d): Static Single Assignment Form (SSA) 621-10F/Topic-1d-SSA 1 Reading List Slides: Topic Ix Other readings as assigned in class 621-10F/Topic-1d-SSA 2 ABET Outcome Ability to apply knowledge of SSA technique in compiler optimization An ability to formulate and solve the basic SSA construction problem based on the techniques introduced in class. Ability to analyze the basic algorithms using SSA form to express and formulate dataflow analysis problem A Knowledge on contemporary issues on this topic. 621-10F/Topic-1d-SSA 3 Roadmap Motivation Introduction: SSA form Construction Method Application of SSA to Dataflow Analysis Problems PRE (Partial Redundancy Elimination) and SSAPRE Summary 621-10F/Topic-1d-SSA 4 Prelude SSA: A program is said to be in SSA form iff Each variable is statically defined exactly only once, and each use of a variable is dominated by that variable’s definition. So, is straight line code in SSA form ? 621-10F/Topic-1d-SSA 5 Example 푿ퟏ In general, how to transform an arbitrary program into SSA form? Does the definition of X 푿ퟐ 2 dominate its use in the example? 푿ퟑ 흓 (푿ퟏ, 푿ퟐ) 푿 ퟒ 621-10F/Topic-1d-SSA 6 SSA: Motivation Provide a uniform basis of an IR to solve a wide range of classical dataflow problems Encode both dataflow and control flow information A SSA form can be constructed and maintained efficiently Many SSA dataflow analysis algorithms are more efficient (have lower complexity) than their CFG counterparts. 621-10F/Topic-1d-SSA 7 Algorithm Complexity Assume a 1 GHz machine, and an algorithm that takes f(n) steps (1 step = 1 nanosecond).
    [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]
  • Fast Online Pointer Analysis
    Fast Online Pointer Analysis MARTIN HIRZEL IBM Research DANIEL VON DINCKLAGE and AMER DIWAN University of Colorado and MICHAEL HIND IBM Research Pointer analysis benefits many useful clients, such as compiler optimizations and bug finding tools. Unfortunately, common programming language features such as dynamic loading, reflection, and foreign language interfaces, make pointer analysis difficult. This article describes how to deal with these features by performing pointer analysis online during program execution. For example, dynamic loading may load code that is not available for analysis before the program starts. Only an online analysis can analyze such code, and thus support clients that optimize or find bugs in it. This article identifies all problems in performing Andersen’s pointer analysis for the full Java language, presents solutions to these problems, and uses a full implementation of the solutions in a Java virtual machine for validation and performance evaluation. Our analysis is fast: On average over our benchmark suite, if the analysis recomputes points-to results upon each program change, most analysis pauses take under 0.1 seconds, and add up to 64.5 seconds. Categories and Subject Descriptors: D.3.4 [Programming Languages]: Processors—Compilers General Terms: Algorithms, Languages Additional Key Words and Phrases: Pointer analysis, class loading, reflection, native interface ACM Reference Format: Hirzel, M., von Dincklage, D., Diwan, A., and Hind, M. 2007. Fast online pointer analysis. ACM Trans. Program. Lang. Syst. 29, 2, Article 11 (April 2007), 55 pages. DOI = 10.1145/1216374. 1216379 http://doi.acm.org/10.1145/1216374.1216379. A preliminary version of parts of this article appeared in the European Conference on Object- Oriented Programming 2004.
    [Show full text]