DOCSLIB.ORG

Do We Still Need New Alias Analyses? Maroua Maalej, Laure Gonnord

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Do We Still Need New Alias Analyses? Maroua Maalej, Laure Gonnord Do we still need new Alias Analyses? Maroua Maalej, Laure Gonnord To cite this version: Maroua Maalej, Laure Gonnord. Do we still need new Alias Analyses?. [Research Report] RR-8812, Université Lyon Claude Bernard / Laboratoire d’Informatique du Parallélisme. 2015. hal-01228581 HAL Id: hal-01228581 https://hal.inria.fr/hal-01228581 Submitted on 13 Nov 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Do we still need new Alias Analyses? Maroua MAALEJ, Laure GONNORD RESEARCH REPORT N° 8812 November 2015 Project-Team ROMA ISSN 0249-6399 ISRN INRIA/RR--8812--FR+ENG Do we still need new Alias Analyses? Maroua MAALEJ∗†‡, Laure GONNORD †‡ Project-Team ROMA Research Report n° 8812 — November 2015 — 18 pages Abstract: Alias analysis is one of the most used techniques that aim to optimize languages with pointers. It is no surprise that this topic has received much attention in many fields including compilation and program verification. However, despite all this attention, a deep study of its state-of-the art shows that it is not handled satisfactorily, by far. In this paper we demonstrate that, although many approaches have been proposed, we still cannot rely on alias analysis inside compilers. We illustrate our statement with an overview of the capabilities of state-of-the-art compilers. Key-words: Static Analysis, Alias Analysis, Optimization, Compilers ∗ This work was supported by the LABEX MILYON (ANR-10-LABX-0070) of Université de Lyon, within the program "Investissements d’Avenir" (ANR-11-IDEX-0007) operated by the French National Research Agency (ANR). † Laboratoire de l’Informatique du Parallélisme, 46 Allée d’Italie, Lyon, France ‡ Université Lyon 1, 43 Boulevard du 11 Novembre, Lyon, France RESEARCH CENTRE GRENOBLE – RHÔNE-ALPES Inovallée 655 avenue de l’Europe Montbonnot 38334 Saint Ismier Cedex A-t-on besoin de nouvelles analyses d’alias ? Résumé : L’analyse d’alias est l’une des techniques les plus utilisées pour optimiser les lan- gages avec pointeurs. C’est donc sans surprise que beaucoup d’approches et d’analyses ont été proposées, à des fins d’optimisation et de vérification de programmes. Cependant, une étude approfondie de l’état de l’art montre que les résultats établis dans le domaine de l’analyse de pointeur sont loin d’être satisfaisants. Dans ce rapport nous montrons qu’en dépit de toutes les approches proposées, nous ne pouvons toujours pas compter sur les analyses d’alias dans les compilateurs. Nous illustrons notre propos par une vue d’ensemble des analyses de pointeurs dans les compilateurs actuels. Mots-clés : Analyses statiques, Analyses d’alias, Optimisation, Compilateurs Do we still need new Alias Analyses? 3 1 Introduction Low-level languages like C are widely used to write embedded software and manage hardware in order to make smaller or more efficient programs. They enable the programmer to finely adapt their code to their hardware, so that it runs faster with minimum memory usage. Today variants of the C language are still used to program on multicore or GPU machines. However, since these languages lack abstractions and give the programmer ability to manip- ulate memory, they are hard to program and are vulnerable to errors. To overcome this problem and to help the user produce correct and optimized code, analysis techniques have been widely investigated in both verification [20] and compilation fields [9]. In this paper we will mainly discuss the field of static alias analyses also known as pointer analyses or points-to analyses that have been shown to be undecidable [32]. This kind of analysis attempts to discover, statically (at compile-time), the possible values of a pointer at runtime. Typically, this information is used to optimize programs or prove their correctness, which can be done by eliminating dead code and null pointers, parallelizing, rescheduling, etc. Many approaches that trade precision for speed, speed for precision, or even attempt to balance between both, have been proposed and improved in time and space. However, we shall demonstrate that despite all the attention this topic has received, today’s compilers still rely on rudimentary and imprecise alias analyses, which provide conservative information insufficient to generate efficient code. The contributions of this paper are the following: • an extensive study of the state-of-the-art approaches for alias analyses (Section 2) and their use for compiler optimizations (Section 3); • an experimental evaluation of strengths and weaknesses of current production C compilers (Section 4); • a discussion of the kind of information that would be useful for designing new pointer analyses for compilers (Section 5). RR n° 8812 4 Maroua MAALEJ & Laure GONNORD 2 Alias analysis: context and related work In this section, we introduce the problem of alias analyses and make an overview of existing approaches. We show that the trade-off between precision and scalability is difficult to find, especially when it comes to compiler optimization. 2.1 Problem statement Alias analysis (or “pointer analysis”) is a technique widely used to perform, on languages with pointers, transformations and optimizations such as parallelization [17] and code motion. It is also useful for program verification such as detecting bugs due to array out of bounds accesses [26, 37] and integer overflow [15, 38]. Some of alias analyses are performed for security and performance enforcement [5, 28], deadlock or race detection [33, 14], memory errors detection [7], etc. Such an analysis aims to disambiguate memory locations pointed by pointer variables to find out whether they dereference overlapping regions or not. At runtime, a pair of pointers may have the following behaviors, depicted in Figure 1: • No Alias: p1 and p2 are disjoint. They do not reference overlapping memory regions. This is the favorable case toward optimizations such as rescheduling and code motion, as we will see in Section 3. • Alias : p1 and p2 reference regions that overlap. In this case, we can distinguish between partial alias where p1 and p2 overlap in some way but do not start at the same address and must alias where p1 and p2 alias and start at the same address. ... ... ... ... ... ... ... p p1 p2 p1 2 p2 p1 noalias partial alias must alias Figure 1: Concrete representation of memory regions in case of no, partial and must aliasing. Each represents a memory slot. The literature of alias analysis is abundant and much work have been done in the last few decades. For a quite exhaustive bibliography, see for instance [12] and [21]. In this paper, we shall be limited to related work that are the most relevant for our study of interest. 2.2 Static analyses of pointers Historically, starting from Andersen’s work [1], static analysis for pointers has received much attention [12, 9, 31, 37]. The current state-of-the-art shows numerous analysis approaches. Constraint-based pointer analyses. Andersen [1] and Steensgaard [36] propose to compute points-to sets (the set of variables that a given pointer can reference) by means of solving con- straint systems. In these two algorithms, a set of constraints is derived from program statements involving assignments, loads and stores. For instance, for any assignment a=b, the points-to set of b is included in the points-to set of a (for Andersen), or the two points-to sets are equal (for Steensgaard). Solving this set of constraints is done with efficient graph algorithms. The output of these algorithms is not a comparison between pointers but a points-to set for each pointer which would enable further use by means of alias queries. The main drawback of these Inria Do we still need new Alias Analyses? 5 algorithms is that they are not precise enough to properly handle pointer arithmetic: after the assignment py=px+4, px and py are inside the same points-to set. Pointer analyses by Model Checking. In [20], alias analysis information is collected by means of model checking techniques. To do so, the relevant features of the C code is represented as a finite state automaton and the alias query is translated into a property verified as a reacha- bility problem. Although the performance in terms of verification time and in scalability seems promising, we believe that such kinds of program transformation cannot be embedded in compil- ers, in particular because tracking back information from results obtained after transformation is tedious and error prone. Shape Analyses. Shape analysis [35, 4], also known as storage analysis, is a kind of static alias analysis mostly used to verify programs that perform destructive updating on dynamically allocated storage. Its goal is to give, for each program point, a finite and conservative character- ization of the possible shapes of program data structures allocated in the heap. A Static Shape Graph (SSG), which is a finite, directed and labeled graph, is computed at each program point to approximate stores done during execution until this point. The SSG, where nodes are structures and edges are pointers, is used to check memory safety (looks for memory leaks), and to find out of bounds accesses and discover properties of linked data structures dynamically allocated. Graphs are used to model program stores. Much attention has been paid to this technique in the last decade. However, the effort has mainly been done on precision issues.
Load more

Recommended publications
  • Using the GNU Compiler Collection (GCC)
    Using the GNU Compiler Collection (GCC) Using the GNU Compiler Collection by Richard M. Stallman and the GCC Developer Community Last updated 23 May 2004 for GCC 3.4.6 For GCC Version 3.4.6 Published by: GNU Press Website: www.gnupress.org a division of the General: [email protected] Free Software Foundation Orders: [email protected] 59 Temple Place Suite 330 Tel 617-542-5942 Boston, MA 02111-1307 USA Fax 617-542-2652 Last printed October 2003 for GCC 3.3.1. Printed copies are available for $45 each. Copyright c 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being \GNU General Public License" and \Funding Free Software", the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled \GNU Free Documentation License". (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. i Short Contents Introduction ...................................... 1 1 Programming Languages Supported by GCC ............ 3 2 Language Standards Supported by GCC ............... 5 3 GCC Command Options .........................
    [Show full text]
  • 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]
  • Memory Tagging and How It Improves C/C++ Memory Safety Kostya Serebryany, Evgenii Stepanov, Aleksey Shlyapnikov, Vlad Tsyrklevich, Dmitry Vyukov Google February 2018
    Memory Tagging and how it improves C/C++ memory safety Kostya Serebryany, Evgenii Stepanov, Aleksey Shlyapnikov, Vlad Tsyrklevich, Dmitry Vyukov Google February 2018 Introduction 2 Memory Safety in C/C++ 2 AddressSanitizer 2 Memory Tagging 3 SPARC ADI 4 AArch64 HWASAN 4 Compiler And Run-time Support 5 Overhead 5 RAM 5 CPU 6 Code Size 8 Usage Modes 8 Testing 9 Always-on Bug Detection In Production 9 Sampling In Production 10 Security Hardening 11 Strengths 11 Weaknesses 12 Legacy Code 12 Kernel 12 Uninitialized Memory 13 Possible Improvements 13 Precision Of Buffer Overflow Detection 13 Probability Of Bug Detection 14 Conclusion 14 Introduction Memory safety in C and C++ remains largely unresolved. A technique usually called “memory tagging” may dramatically improve the situation if implemented in hardware with reasonable overhead. This paper describes two existing implementations of memory tagging: one is the full hardware implementation in SPARC; the other is a partially hardware-assisted compiler-based tool for AArch64. We describe the basic idea, evaluate the two implementations, and explain how they improve memory safety. This paper is intended to initiate a wider discussion of memory tagging and to motivate the CPU and OS vendors to add support for it in the near future. Memory Safety in C/C++ C and C++ are well known for their performance and flexibility, but perhaps even more for their extreme memory unsafety. This year we are celebrating the 30th anniversary of the Morris Worm, one of the first known exploitations of a memory safety bug, and the problem is still not solved.
    [Show full text]
  • Statically Detecting Likely Buffer Overflow Vulnerabilities
    Statically Detecting Likely Buffer Overflow Vulnerabilities David Larochelle [email protected] University of Virginia, Department of Computer Science David Evans [email protected] University of Virginia, Department of Computer Science Abstract Buffer overflow attacks may be today’s single most important security threat. This paper presents a new approach to mitigating buffer overflow vulnerabilities by detecting likely vulnerabilities through an analysis of the program source code. Our approach exploits information provided in semantic comments and uses lightweight and efficient static analyses. This paper describes an implementation of our approach that extends the LCLint annotation-assisted static checking tool. Our tool is as fast as a compiler and nearly as easy to use. We present experience using our approach to detect buffer overflow vulnerabilities in two security-sensitive programs. 1. Introduction ed a prototype tool that does this by extending LCLint [Evans96]. Our work differs from other work on static detection of buffer overflows in three key ways: (1) we Buffer overflow attacks are an important and persistent exploit semantic comments added to source code to security problem. Buffer overflows account for enable local checking of interprocedural properties; (2) approximately half of all security vulnerabilities we focus on lightweight static checking techniques that [CWPBW00, WFBA00]. Richard Pethia of CERT have good performance and scalability characteristics, identified buffer overflow attacks as the single most im- but sacrifice soundness and completeness; and (3) we portant security problem at a recent software introduce loop heuristics, a simple approach for engineering conference [Pethia00]; Brian Snow of the efficiently analyzing many loops found in typical NSA predicted that buffer overflow attacks would still programs.
    [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]
  • Aliasing Restrictions of C11 Formalized in Coq
    Aliasing restrictions of C11 formalized in Coq Robbert Krebbers Radboud University Nijmegen December 11, 2013 @ CPP, Melbourne, Australia int f(int *p, int *q) { int x = *p; *q = 314; return x; } If p and q alias, the original value n of *p is returned n p q Optimizing x away is unsound: 314 would be returned Alias analysis: to determine whether pointers can alias Aliasing Aliasing: multiple pointers referring to the same object Optimizing x away is unsound: 314 would be returned Alias analysis: to determine whether pointers can alias Aliasing Aliasing: multiple pointers referring to the same object int f(int *p, int *q) { int x = *p; *q = 314; return x; } If p and q alias, the original value n of *p is returned n p q Alias analysis: to determine whether pointers can alias Aliasing Aliasing: multiple pointers referring to the same object int f(int *p, int *q) { int x = *p; *q = 314; return x *p; } If p and q alias, the original value n of *p is returned n p q Optimizing x away is unsound: 314 would be returned Aliasing Aliasing: multiple pointers referring to the same object int f(int *p, int *q) { int x = *p; *q = 314; return x; } If p and q alias, the original value n of *p is returned n p q Optimizing x away is unsound: 314 would be returned Alias analysis: to determine whether pointers can alias It can still be called with aliased pointers: x union { int x; float y; } u; y u.x = 271; return h(&u.x, &u.y); &u.x &u.y C89 allows p and q to be aliased, and thus requires it to return 271 C99/C11 allows type-based alias analysis: I A compiler
    [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]
  • Teach Yourself Perl 5 in 21 Days
    Teach Yourself Perl 5 in 21 days David Till Table of Contents: Introduction ● Who Should Read This Book? ● Special Features of This Book ● Programming Examples ● End-of-Day Q& A and Workshop ● Conventions Used in This Book ● What You'll Learn in 21 Days Week 1 Week at a Glance ● Where You're Going Day 1 Getting Started ● What Is Perl? ● How Do I Find Perl? ❍ Where Do I Get Perl? ❍ Other Places to Get Perl ● A Sample Perl Program ● Running a Perl Program ❍ If Something Goes Wrong ● The First Line of Your Perl Program: How Comments Work ❍ Comments ● Line 2: Statements, Tokens, and <STDIN> ❍ Statements and Tokens ❍ Tokens and White Space ❍ What the Tokens Do: Reading from Standard Input ● Line 3: Writing to Standard Output ❍ Function Invocations and Arguments ● Error Messages ● Interpretive Languages Versus Compiled Languages ● Summary ● Q&A ● Workshop ❍ Quiz ❍ Exercises Day 2 Basic Operators and Control Flow ● Storing in Scalar Variables Assignment ❍ The Definition of a Scalar Variable ❍ Scalar Variable Syntax ❍ Assigning a Value to a Scalar Variable ● Performing Arithmetic ❍ Example of Miles-to-Kilometers Conversion ❍ The chop Library Function ● Expressions ❍ Assignments and Expressions ● Other Perl Operators ● Introduction to Conditional Statements ● The if Statement ❍ The Conditional Expression ❍ The Statement Block ❍ Testing for Equality Using == ❍ Other Comparison Operators ● Two-Way Branching Using if and else ● Multi-Way Branching Using elsif ● Writing Loops Using the while Statement ● Nesting Conditional Statements ● Looping Using
    [Show full text]
  • User-Directed Loop-Transformations in Clang
    User-Directed Loop-Transformations in Clang Michael Kruse Hal Finkel Argonne Leadership Computing Facility Argonne Leadership Computing Facility Argonne National Laboratory Argonne National Laboratory Argonne, USA Argonne, USA [email protected] hfi[email protected] Abstract—Directives for the compiler such as pragmas can Only #pragma unroll has broad support. #pragma ivdep made help programmers to separate an algorithm’s semantics from popular by icc and Cray to help vectorization is mimicked by its optimization. This keeps the code understandable and easier other compilers as well, but with different interpretations of to optimize for different platforms. Simple transformations such as loop unrolling are already implemented in most mainstream its meaning. However, no compiler allows applying multiple compilers. We recently submitted a proposal to add generalized transformations on a single loop systematically. loop transformations to the OpenMP standard. We are also In addition to straightforward trial-and-error execution time working on an implementation in LLVM/Clang/Polly to show its optimization, code transformation pragmas can be useful for feasibility and usefulness. The current prototype allows applying machine-learning assisted autotuning. The OpenMP approach patterns common to matrix-matrix multiplication optimizations. is to make the programmer responsible for the semantic Index Terms—OpenMP, Pragma, Loop Transformation, correctness of the transformation. This unfortunately makes it C/C++, Clang, LLVM, Polly hard for an autotuner which only measures the timing difference without understanding the code. Such an autotuner would I. MOTIVATION therefore likely suggest transformations that make the program Almost all processor time is spent in some kind of loop, and return wrong results or crash.
    [Show full text]