DOCSLIB.ORG

Effective Representation of Aliases and Indirect Memory Operations in SSA Form

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Effective Representation of Aliases and Indirect Memory Operations in SSA Form Effective Representation of Aliases and Indirect Memory Operations in SSA Form Fred Chow, Sun Chan, Shin-Ming Liu, Raymond Lo, Mark Streich Silicon Graphics Computer Systems 2011 N. Shoreline Blvd. Mountain View, CA 94043 Contact: Fred Chow (E-mail: [email protected], Phone: USA (415) 933-4270) Abstract. This paper addresses the problems of representing aliases and indirect memory operations in SSA form. We propose a method that prevents explosion in the number of SSA variable versions in the presence of aliases. We also present a technique that allows indirect memory operations to be globally commonized. The result is a precise and compact SSA representation based on global value numbering, called HSSA, that uniformly handles both scalar variables and indi- rect memory operations. We discuss the capabilities of the HSSA representation and present measurements that show the effects of implementing our techniques in a production global optimizer. Keywords. Aliasing, Factoring dependences, Hash tables, Indirect memory oper- ations, Program representation, Static single assignment, Value numbering. 1 Introduction The Static Single Assignment (SSA) form [CFR+91] is a popular and efficient represen- tation for performing analyses and optimizations involving scalar variables. Effective algorithms based on SSA have been developed to perform constant propagation, redun- dant computation detection, dead code elimination, induction variable recognition, and others [AWZ88, RWZ88, WZ91, Wolfe92]. But until now, SSA has only been used mostly for distinct variable names in the program. When applied to indirect variable constructs, the representation is not straight-forward, and results in added complexities in the optimization algorithms that operate on the representation [CFR+91, CG93, CCF94]. This has prevented SSA from being widely used in production compilers. In this paper, we devise a scheme that allows indirect memory operations to be rep- resented together with ordinary scalar variables in SSA form. Since indirect memory accesses also affect scalar variables due to aliasing, we start by defining notations to model the effects of aliasing for scalars in SSA form. We also describe a technique to reduce the overhead in SSA representation in the presence of aliases. Next, we intro- duce the concept of virtual variables, which model indirect memory operations as if they are scalars. We then show how virtual variables can be used to derive identical or distinct versions for indirect memory operations, effectively putting them in SSA form together with the scalar variables. This SSA representation in turn reduces the cost of analyzing the scalar variables that have aliases by taking advantage of the versioning applied to the indirect memory operations aliased with the scalar variables. We then present a method that builds a uniform SSA representation of all the scalar and indirect 254 memory operations of the program based on global value numbering, which we call the Hashed SSA representation (HSSA). The various optimizations for scalars can then automatically extend to indirect memory operations under this framework. Finally, we present measurements that show the effectiveness of our techniques in a production glo- bal optimizer that uses HSSA as its internal representation. In this paper, indirect memory operations cover both the uses of arrays and accesses to memory locations through pointers. Our method is applicable to commonly used lan- guages like C and FORTRAN. 2 SSA with Aliasing In our discussion, the source program has been translated to an intermediate representa- tion in which expressions are represented in tree form. The expression trees are associ- ated with statements that use their computed results. In SSA form, each definition of a variable is given a unique version, and different versions of the same variable can be regarded as different program variables. Each use of a variable version can only refer to a single reaching definition. When several definitions of a variable, a 1, a 2 ..... a m, reach a confluence node in the control flow graph of the pro~am, a t~ function assignment statement, a n = t~(a 1, a 2 ..... am), is inserted to merge them into the definition of a new variable version a n . Thus, the semantics of single reaching definitions is maintained. This introduction of a new variable version as the result of t~ factors use-def edges over confluence nodes, reducing the total number of use-def edges required. As a result, the use-def chain of each variable can be provided in a compact form by trivially allowing each variable to point to its single definition. One important property in SSA form is that each definition must dominate all its uses in the control flow graph of the program. Another important property in SSA form is that identical versions of the same variable must have the same value. Aliasing of a scalar variable occurs in one of four conditions: when its storage loca- tion partially overlaps another variable l, when it is pointed to by a pointer used in indi- rect memory operations, when its address is passed in a procedure call, or when it is a non-local variable that can be accessed from another procedure in a call or return. Tech- niques have been developed to analyze pointers both intra-procedurally and inter-proce- durally to provide more accurate information on what is affected by them so as to limit their ill effects on program optimizations [CWZ90, CBC93, Ruf95, WL95]. To characterize the effects of aliasing, we distinguish between two types of defini- tions of a variable: MustDefand MayDef 2 Since a MustDef must redefine the variable, it blocks the references of previous definitions from that point on. A MayDef only potentially redefines the variable, and so does not prevent previous definitions of the 1. If they exactly overlap, our representation will handle them as a single variable. 2. In [CCF94], MustDefs and MayDefs are called Killing Defs and Preserving Defs respec- tively, while in [Steen95], they are called Strong Updates and Weak Updates. 255 Original Program: SSA Representation: i 4--2 ij <---2 if(j) if(j1) \ *p +--- 3 call funcO *p ~-- 3 call funcO ".,,/ / i2~--Z(il) i3+--~(il, i2) return i return i3 Fig. 1. Example of It, X and same variable from being reterenced later in the program. On the use side, in addition to real uses of the variable, there are places in the program where there are potential refer- ences to the variable that need to be taken into account in analyzing the program. We call these potential references MayUse. To accommodate the MayDefs, we use the idea from [CCF94] in which SSA edges for the same variable are factored over its MayDefs. This is referred to as location-fac- tored SSA form in [Steen95]. We model this effect by introducing the Z assignment operator in our SSA representation. ~ links up the use-def edges through MayDefs. The operand of Z is the last version of the variable, and its result is the version after the potential definition. Thus, if variable i may be modified, we annotate the code with i 2 = )~(il) , where i I is the current version of the variable. To model MayUses, we introduce the It operator in our SSA representation, tx takes as its operand the version of the variable that may be referenced, and produces no result. Thus, if variable i may be referenced, we annotate the code with It(il), where i I is the current version of the variable. In our internal representation, expressions cannot have side effects. Memory loca- tions can only be modified by statements, which include direct and indirect store state- ments and calls. Thus, Z can only be associated with store and call statements. I.t is associated with any dereferencing operation, like the unary operator * in C, which can happen within an expression. Thus, t.t arises at both statements and expressions. We also mark return statements with It for non-local variables to represent their liveness at func- tion exits. Separating MayDefand MayUse allows us to model the effects of calls pre- cisely. For example, a call that only references a variable will only cause a I1 but no ~. For our modeling purpose, the It takes effect just before the call, and the Z takes effect right after the call. Figure 1 gives an example of the use of Ix, ;~ together with ~ in our SSA representation. In the example, functionfunc uses but does not modify variable i. The inclusion of It and Z in the SSA form does not impact the complexity of the algorithm that computes SSA form. A pre-pass inserts unnamed It's and X~ for the 256 aliased variables at the points of aliases in the program. In applying the SSA creation algorithm described in [CFR+91 ], the operands of the ~t and Z are treated as uses and the ~'s are treated as additional assignments. The variables in the Ix and X are renamed together with the rest of the program variables. Transformations performed on SSA form have to take aliasing into account in order to preserve the safety of the optimization. In our SSA representation, it means taking_ into account the IX and ~ annotations. For example, in performing dead code elimination using the algorithm presented in [CFR+91], a store can be deleted only if the store itself and all its associated ~'s are not marked live. 3 SSA with Zero Versioning In the previous section, we showed how to use IX and ;~ to model use-def information when aliases occur in a program. Even though use-def information is maintained, the number of versions multiplies because each ~ introduces a new version and it may in turn cause new ~'s to be inserted. Many of these versions have multiple possibly- defined values, and some of the defined values may also be unknown.
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]
  • 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]
  • 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]
  • 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]
  • 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]
  • Towards Restrict-Like Aliasing Semantics for C++ Abstract
    Document Number: N3988 Date: 2014-05-23 Authors: Hal Finkel, [email protected] Hubert Tong, [email protected] Chandler Carruth, [email protected], Clark Nelson, [email protected], Daveed Vandevoode, [email protected], Michael Wong, [email protected] Project: Programming Language C++, EWG Reply to: [email protected] Revision: 1 Towards restrict-like aliasing semantics for C++ Abstract This paper is a follow-on to N3635 after a design discussion with many compiler implementers at Issaquah, and afterwards by telecon, and specifically proposes a new alias_set attribute as a way to partition type-based aliasing to enable more fine grain control, effectively giving C++ a more complete restrict-like aliasing syntax and semantics. Changes from previous papers: N3988: this paper updates with syntax and semantics N3635: Outlined initial idea on AliasGroup which became alias_set. The alternative of newType was rejected as too heavy weight of a solution. 1. Problem Domain There is no question that the restrict qualifier benefits compiler optimization in many ways, notably allowing improved code motion and elimination of loads and stores. Since the introduction of C99 restrict, it has been provided as a C++ extension in many compilers. But the feature is brittle in C++ without clear rules for C++ syntax and semantics. Now with the introduction of C++11, functors are being replaced with lambdas and users have begun asking how to use restrict in the presence of lambdas. Given the existing compiler support, we need to provide a solution with well-defined C++ semantics, before use of some common subset of C99 restrict becomes widely used in combination with C++11 constructs.
    [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]
  • Program Sequentially, Carefully, and Benefit from Compiler Advances For
    Program Sequentially, Carefully, and Benefit from Compiler Advances for Parallel Heterogeneous Computing Mehdi Amini, Corinne Ancourt, Béatrice Creusillet, François Irigoin, Ronan Keryell To cite this version: Mehdi Amini, Corinne Ancourt, Béatrice Creusillet, François Irigoin, Ronan Keryell. Program Se- quentially, Carefully, and Benefit from Compiler Advances for Parallel Heterogeneous Computing. Magoulès Frédéric. Patterns for Parallel Programming on GPUs, Saxe-Coburg Publications, pp. 149- 169, 2012, 978-1-874672-57-9 10.4203/csets.34.6. hal-01526469 HAL Id: hal-01526469 https://hal-mines-paristech.archives-ouvertes.fr/hal-01526469 Submitted on 30 May 2017 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. Program Sequentially, Carefully, and Benefit from Compiler Advances for Parallel Heterogeneous Computing Mehdi Amini1;2 Corinne Ancourt1 B´eatriceCreusillet2 Fran¸coisIrigoin1 Ronan Keryell2 | 1MINES ParisTech/CRI, firstname.lastname @mines-paristech.fr 2SILKAN, firstname.lastname @silkan.com September 26th 2012 Abstract The current microarchitecture trend leads toward heterogeneity. This evolution is driven by the end of Moore's law and the frequency wall due to the power wall. Moreover, with the spreading of smartphone, some constraints from the mobile world drive the design of most new architectures.
    [Show full text]
  • Alias-Free Parameters in C Using Multibodies Medhat Assaad Iowa State University
    Computer Science Technical Reports Computer Science 7-2001 Alias-free parameters in C using multibodies Medhat Assaad Iowa State University Follow this and additional works at: http://lib.dr.iastate.edu/cs_techreports Part of the Programming Languages and Compilers Commons, and the Theory and Algorithms Commons Recommended Citation Assaad, Medhat, "Alias-free parameters in C using multibodies" (2001). Computer Science Technical Reports. 301. http://lib.dr.iastate.edu/cs_techreports/301 This Article is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Alias-free parameters in C using multibodies Abstract Aliasing may cause problems for both optimization and reasoning about programs. Since static alias analysis is expensive, and sometimes, even impossible, compilers tend to be conservative. This usually leads to missing some optimization opportunities. Furthermore, when trying to understand code, one must consider all possible aliasing patterns. This can make reasonning about code difficult and non-trivial. We have implemented an approach for having alias-free parameters in C. This approach allows aliasing between the arguments at the call site, but guarantees that there will be no aliasing between arguments and between arguments and globals inside procedure bodies. This is done by having multiple bodies, up to one for each aliasing pattern. Procedure calls will be dispatched to the body that matches the aliasing pattern at the call site. By having alias-free parameters in the bodies, good optimization can be achieved.
    [Show full text]