DOCSLIB.ORG

PL/I Optimizing Compiler: Program Product General Information

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

GC33-0001-2 File No. S360/S370-29 OS PL/I Optimizing Compiler: Program Product General Information Program Number 5734-PL 1 (This program product is available as part of composite package 5734-PL3) Reiised June~ 1973 By TNL: GN33-6095 Preface This publication gives general information substitution of in-line code in place of about the Q§ !:!!L! QE:£!!!!iz!!!g £2!!lE!!~!:" a calls to library subroutines. processing program of the IBM Operating :System. Chapter 3 is about the PL/I language itself, including the features that can be The information provided is to be used used with this compiler, and a comparison as a planning aid only, and is intended to of the language imple~ented by the introduce installation managers, systems optimizing compiler with that implemented .analysts, and programmers to the facilities by version 5 of the PL/I (F) compiler. available with this compiler. The reader is assumed to be conversant with the IBM Chapter 4 briefly describes both the operating System and with the PL/I language machine and the operating system as implemented by version 5 of the PL/I (F) requirements of the optimizing compiler. compiler. Appendix A is a list of the PL/I and the Chapter 1 discusses how the performance implementation-defined keywords used by of the OS PL/I Optimizing Compiler compares this compiler. with that of version 5 of the PL/I (F) Compiler; the compiler options that are Appendix B documents the most available; the debugging aids designed to significant incompatibilities that might increase programmer productivity; the cause a program written for version 5 of degree to which the compiler is compatible the PL/I (F) Compiler to give errors when with version 5 of the PL/I (F) Compiler; run on the optimizing compiler. and the features designed to allow I communication with assembler programs and Appendix C is a bibliography of related Iwith programs written in COBOL or FORTRAN. IBM publications and their order numbers. Chapter 2 is a discussion of the methods Appendix 0 provides planning information used for the optimization process;, such as for the use of the optimizing compiler expression simplification or the under CMS. Third Edition (December 1972) This is a major revision of, and obsoletes, GC33-0001-1 and Technical Newsletters GN33-6069, GN33-6057, GN33-6044. GN33-6034, and GN33-6024. Changes or additions to the text and figures are indicated by a vertical line to the left of the change. This edition applies to Version 1, Release 2, Modification 0 of the OS PL/I Optimizing Compiler, Program Product 5734-PL1, and to all subsequent versions, releases, or modifications until otherwise indicated in new editions or technical newsletters. Changes are continually made to the information herein; before using this pUblication in connection with the operation ot IBM Systems, consult the latest IBM System/360 and System/370 Bibliography, Order No. GA22-6822, and associated technical newsletters, for the editions that are applicable and current. VSAM material in this publication is for planning purposes only. CMS material in this publication applies to Release 1, PLC5(Program Level Change 5) of the Virtual Machine Facility/370 (VM/370). Requests for copies of IBM publications should be made to your IBM representative or the IBM branch office serving your locality. A form for readers' comments is provided at the back of this publication. If the form has been removed, comments may be addressed to IBM united Kingdom Laboratories Ltd. Publications Department, Hursley Park, Winchester' Hampshire, England. Comments become the property'of IBM. ecopyright International Business Machines Corporation 1970,1971,1972 ii Contents INTRODUCTION 1 Data Aggregates • • • • 18 String Handling • • • • • 18 CHAPTER 1: THE OS PL/I OPTIMIZING Data Attributes 18 COMPILER • 3 Extended Precision Floating Compilation Speed • • 3 Point • • • • • • • • • • • 19 Execution Speed • • • • • • • • • • • 3 Subroutines and Functions 19 Space Requirements . 3 Mathematical Built-In Functions 20 Debugging Aids 3 comparison Operators • • • • 20 Compiler Options 4 Interlanguage Communication 20 Compatibility with the (F) Compiler • 5 compatibility Between Releases • • • 5 compatibility Between OS and DOS 5 CHAPTER 4: SYSTEM REQUIREMENTS • 21 Interlanguage Communication 5 Machine Requirements 21 Compilation . 21 CHAPTER 2: OPTIMIZATION 7 Execution •••• . 21 Common Expression Elimination 7 Auxiliary Storage 21 Transfer of Expressions from Loops 8 Input/Output Devices • 21 Redundant Expression Elimination 8 Operating System Requirements 22 Simplification of Expressions • • 8 Control Programs • • • • • • • 22 Modification of Loop Control Data Management Facilities • • 23 Variables • • • • • • • 9 Sort Facilities •••••• 23 Defactorization • • • • 9 Checkpoint/Restart Facilities 23 Replacement of constant System/370 Facilities 23 Expressions • • • • • • 9 Replacement of Constant APPENDIX A: KEYWORDS AND THEIR Multipliers and Exponents • 9 ABBREVIATIONS 25 Initialization of Arrays and Structures • • • • • • • • • 9 APPENDIX B: COMPATIBILITY WITH (F) In-line Code for Conversions 10 COMPILER • 31 In-line Code for RECORD I/O • • • 10 Areas ••••••••• 31 Rey Handling for REGIONAL Data Sets • 10 Arrays and structures • • • • • 31 Matching Format Lists With Data Lists 10 Built-In Functions • • 31 In-line Code for String Manipulation 10 The DISPLAY Statement 31 In-line Code for Built-In Functions • 10 Dumps from PL/I Programs • • 31 Special-case Code for DO Statements • 10 Entry Names, Parameters, and structure and Array Assignments • 11 Returned Values • • • • • • • • 31 Library Subroutines • • • • • • • • • 11 The ENVIRONMENT Attribute 32 Elimination of Common Constants • • • 11 Error Correction • 32 Elimination of Common Control Data 11 INITIAL Attribute 32 Use of Registers 11 LIKE Attribute • 32 Code for Program Branches • • • • • • 11 Link-Editing • • • 32 Operating System Facilities 32 CHAPTER 3: THE PL/I LANGUAGE Pictures • • • • 33 IMPLEMENTED • • • • 13 Preprocessor • • 33 Language Feature s • • • • • • 13 Pseudovariables 33 Data Types • • • 13 Record I/O ••• 33 Operations • • • • • • • 13 Redundant Expression Elimination 33 Data Aggregates 13 REWIND Option 33 Program Management • 13 SORT/MERGE Program • 33 Input/Output •• 14 Statements • • • • • • • • • 33 Language Extensions • • • 15 Statement Labels • • • • • • 33 optimization • • • • 15 statement Lengths 33 Program Checkout • 15 Stream Transmission 34 DEFAULT Statement 15 Varying-length strings • • • • • 34 preprocessing Facilities • 15 Listing Control Statements 16 APPENDIX C: BIBLIOGRAPHY. 35 storage Control •••••• 16 ENVIRONMENT Attribute 16 APPENDIX D: PLANNING INFORMATION FOR Record-Oriented Transmission • • 17 CMS • • • • • 37 ASCII Data Sets 17 File Names • • • • • • • • • 18 INDEX • 39 iii Figures Figure 1. Differences in implementation restrictions 14 Figure 2. Compiler input/outputdevices •••••• 22 iv --~- -- ---- ---- - Revised June, 1973 By TNL: GN33-6095 Introduction The OS PL/I Optimizing Compiler is designed The OS PL/I Optimizing Compiler for the compilation of programs written in translates PL/I source statements into PL/I into efficient object programs. It machine instructions. However, it does not requires a minimum of 50K bytes of main generate all the machine instructions storage on an IBM System/360 or System/370 required to represent the source program; with the universal instruction set and is in some cases it inserts references to intended to meet the requirements of the subroutines that are stored in the resident PL/I user of medium-sized or larger library. During link-editing, subroutines installations. Good all-round performance from the resident library are included in is aChieved by a compiler design that the object module. These subroutines may incorporates the best design features of a contain references to other subroutines number of well-proven compilers, including stored in the transient library; during the PL/I (D)~ PL/I (F), FORTRAN IV(G), execution, subroutines from the transient FORTRAN IV(H), and COBOL (F) compilers. library are loaded, executed, and discarded The main features include: as required. • Extensive Optimization - if optional The functions provided by the resident optimization is specified, the machine library are as follows: instructions generated will be optimized using the features described in chapter • mathematical subroutines. 2, to produce a very efficient object program. some optimization is always • data type conversions. performed even if the option is not specified. A secondary effect of • edit-, list-, and data-directed I/O optimization could be a reduction in the (stream-oriented transmission). amount of main storage required for the object program during execution. If • program initialization. optional optimization is not specified" compilation time will be reduced. • storage management. • Advanced Level of PL/I - an • display. implementation of PL/I with language extensions beyond the language • timer facilities. implemented by the PL/I (F) Compiler. New features for os users include: • error handling. DEFAULT statement The functions provided by the transient library are as follows: Entry variables • print and message subroutines of the File variables error and interrupt handling subroutines. • Extensive Debugging Aids - time and effort required for program checkout are • opening and closing files. minimized by: • record-oriented and stream-oriented Extensive implementation of on-units transmission. support of the CHECK condition These
Recommended publications
  • The LLVM Instruction Set and Compilation Strategy

    The LLVM Instruction Set and Compilation Strategy

    The LLVM Instruction Set and Compilation Strategy Chris Lattner Vikram Adve University of Illinois at Urbana-Champaign lattner,vadve ¡ @cs.uiuc.edu Abstract This document introduces the LLVM compiler infrastructure and instruction set, a simple approach that enables sophisticated code transformations at link time, runtime, and in the field. It is a pragmatic approach to compilation, interfering with programmers and tools as little as possible, while still retaining extensive high-level information from source-level compilers for later stages of an application’s lifetime. We describe the LLVM instruction set, the design of the LLVM system, and some of its key components. 1 Introduction Modern programming languages and software practices aim to support more reliable, flexible, and powerful software applications, increase programmer productivity, and provide higher level semantic information to the compiler. Un- fortunately, traditional approaches to compilation either fail to extract sufficient performance from the program (by not using interprocedural analysis or profile information) or interfere with the build process substantially (by requiring build scripts to be modified for either profiling or interprocedural optimization). Furthermore, they do not support optimization either at runtime or after an application has been installed at an end-user’s site, when the most relevant information about actual usage patterns would be available. The LLVM Compilation Strategy is designed to enable effective multi-stage optimization (at compile-time, link-time, runtime, and offline) and more effective profile-driven optimization, and to do so without changes to the traditional build process or programmer intervention. LLVM (Low Level Virtual Machine) is a compilation strategy that uses a low-level virtual instruction set with rich type information as a common code representation for all phases of compilation.
  • Opencobol Manual for Opencobol 2.0

    Opencobol Manual for Opencobol 2.0

    OpenCOBOL Manual for OpenCOBOL 2.0 Keisuke Nishida / Roger While Edition 2.0 Updated for OpenCOBOL 2.0 26 January 2012 OpenCOBOL is an open-source COBOL compiler, which translates COBOL programs to C code and compiles it using GCC or other C compiler system. This manual corresponds to OpenCOBOL 2.0. Copyright c 2002,2003,2004,2005,2006 Keisuke Nishida Copyright c 2007-2012 Roger While Permission is granted to make and distribute verbatim copies of this manual provided the copy- right notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the condi- tions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice maybe stated in a translation approved by the Free Software Foundation. i Table of Contents 1 Getting Started :::::::::::::::::::::::::::::::::::::::::::::::: 1 1.1 Hello World!::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1 2 Compile :::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2 2.1 Compiler Options ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2 2.1.1 Help Options ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2 2.1.2 Built Target ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
  • Scribble As Preprocessor

    Scribble As Preprocessor

    Scribble as Preprocessor Version 8.2.0.8 Matthew Flatt and Eli Barzilay September 25, 2021 The scribble/text and scribble/html languages act as “preprocessor” languages for generating text or HTML. These preprocessor languages use the same @ syntax as the main Scribble tool (see Scribble: The Racket Documentation Tool), but instead of working in terms of a document abstraction that can be rendered to text and HTML (and other formats), the preprocessor languages work in a way that is more specific to the target formats. 1 Contents 1 Text Generation 3 1.1 Writing Text Files . .3 1.2 Defining Functions and More . .7 1.3 Using Printouts . .9 1.4 Indentation in Preprocessed output . 11 1.5 Using External Files . 16 1.6 Text Generation Functions . 19 2 HTML Generation 23 2.1 Generating HTML Strings . 23 2.1.1 Other HTML elements . 30 2.2 Generating XML Strings . 32 2.3 HTML Resources . 36 Index 39 Index 39 2 1 Text Generation #lang scribble/text package: scribble-text-lib The scribble/text language provides everything from racket/base, racket/promise, racket/list, and racket/string, but with additions and a changed treatment of the module top level to make it suitable as for text generation or a preprocessor language: • The language uses read-syntax-inside to read the body of the module, similar to §6.7 “Document Reader”. This means that by default, all text is read in as Racket strings; and @-forms can be used to use Racket functions and expression escapes. • Values of expressions are printed with a custom output function.
  • Analysis of Program Optimization Possibilities and Further Development

    Analysis of Program Optimization Possibilities and Further Development

    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Elsevier - Publisher Connector Theoretical Computer Science 90 (1991) 17-36 17 Elsevier Analysis of program optimization possibilities and further development I.V. Pottosin Institute of Informatics Systems, Siberian Division of the USSR Acad. Sci., 630090 Novosibirsk, USSR 1. Introduction Program optimization has appeared in the framework of program compilation and includes special techniques and methods used in compiler construction to obtain a rather efficient object code. These techniques and methods constituted in the past and constitute now an essential part of the so called optimizing compilers whose goal is to produce an object code in run time, saving such computer resources as CPU time and memory. For contemporary supercomputers, the requirement of the proper use of hardware peculiarities is added. In our opinion, the existence of a sufficiently large number of optimizing compilers with real possibilities of producing “good” object code has evidently proved to be practically significant for program optimization. The methods and approaches that have accumulated in program optimization research seem to be no lesser valuable, since they may be successfully used in the general techniques of program construc- tion, i.e. in program synthesis, program transformation and at different steps of program development. At the same time, there has been criticism on program optimization and even doubts about its necessity. On the one hand, this viewpoint is based on blind faith in the new possibilities bf computers which will be so powerful that any necessity to worry about program efficiency will disappear.
  • Section “Common Predefined Macros” in the C Preprocessor

    Section “Common Predefined Macros” in the C Preprocessor

    The C Preprocessor For gcc version 12.0.0 (pre-release) (GCC) Richard M. Stallman, Zachary Weinberg Copyright c 1987-2021 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.3 or any later version published by the Free Software Foundation. A copy of the license is included in the section entitled \GNU Free Documentation License". This manual contains no Invariant Sections. The Front-Cover Texts are (a) (see below), and the Back-Cover Texts are (b) (see below). (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 Table of Contents 1 Overview :::::::::::::::::::::::::::::::::::::::: 1 1.1 Character sets:::::::::::::::::::::::::::::::::::::::::::::::::: 1 1.2 Initial processing ::::::::::::::::::::::::::::::::::::::::::::::: 2 1.3 Tokenization ::::::::::::::::::::::::::::::::::::::::::::::::::: 4 1.4 The preprocessing language :::::::::::::::::::::::::::::::::::: 6 2 Header Files::::::::::::::::::::::::::::::::::::: 7 2.1 Include Syntax ::::::::::::::::::::::::::::::::::::::::::::::::: 7 2.2 Include Operation :::::::::::::::::::::::::::::::::::::::::::::: 8 2.3 Search Path :::::::::::::::::::::::::::::::::::::::::::::::::::: 9 2.4 Once-Only Headers::::::::::::::::::::::::::::::::::::::::::::: 9 2.5 Alternatives to Wrapper #ifndef ::::::::::::::::::::::::::::::
  • Julia: a Fresh Approach to Numerical Computing

    Julia: a Fresh Approach to Numerical Computing

    RSDG @ UCL Julia: A Fresh Approach to Numerical Computing Mosè Giordano @giordano [email protected] Knowledge Quarter Codes Tech Social October 16, 2019 Julia’s Facts v1.0.0 released in 2018 at UCL • Development started in 2009 at MIT, first • public release in 2012 Julia co-creators won the 2019 James H. • Wilkinson Prize for Numerical Software Julia adoption is growing rapidly in • numerical optimisation, differential equations, machine learning, differentiable programming It is used and taught in several universities • (https://julialang.org/teaching/) Mosè Giordano (RSDG @ UCL) Julia: A Fresh Approach to Numerical Computing October 16, 2019 2 / 29 Julia on Nature Nature 572, 141-142 (2019). doi: 10.1038/d41586-019-02310-3 Mosè Giordano (RSDG @ UCL) Julia: A Fresh Approach to Numerical Computing October 16, 2019 3 / 29 Solving the Two-Language Problem: Julia Multiple dispatch • Dynamic type system • Good performance, approaching that of statically-compiled languages • JIT-compiled scripts • User-defined types are as fast and compact as built-ins • Lisp-like macros and other metaprogramming facilities • No need to vectorise: for loops are fast • Garbage collection: no manual memory management • Interactive shell (REPL) for exploratory work • Call C and Fortran functions directly: no wrappers or special APIs • Call Python functions: use the PyCall package • Designed for parallelism and distributed computation • Mosè Giordano (RSDG @ UCL) Julia: A Fresh Approach to Numerical Computing October 16, 2019 4 / 29 Multiple Dispatch using DifferentialEquations
  • Register Allocation and Method Inlining

    Register Allocation and Method Inlining

    Combining Offline and Online Optimizations: Register Allocation and Method Inlining Hiroshi Yamauchi and Jan Vitek Department of Computer Sciences, Purdue University, {yamauchi,jv}@cs.purdue.edu Abstract. Fast dynamic compilers trade code quality for short com- pilation time in order to balance application performance and startup time. This paper investigates the interplay of two of the most effective optimizations, register allocation and method inlining for such compil- ers. We present a bytecode representation which supports offline global register allocation, is suitable for fast code generation and verification, and yet is backward compatible with standard Java bytecode. 1 Introduction Programming environments which support dynamic loading of platform-indep- endent code must provide supports for efficient execution and find a good balance between responsiveness (shorter delays due to compilation) and performance (optimized compilation). Thus, most commercial Java virtual machines (JVM) include several execution engines. Typically, there is an interpreter or a fast com- piler for initial executions of all code, and a profile-guided optimizing compiler for performance-critical code. Improving the quality of the code of a fast compiler has the following bene- fits. It raises the performance of short-running and medium length applications which exit before the expensive optimizing compiler fully kicks in. It also ben- efits long-running applications with improved startup performance and respon- siveness (due to less eager optimizing compilation). One way to achieve this is to shift some of the burden to an offline compiler. The main question is what optimizations are profitable when performed offline and are either guaranteed to be safe or can be easily validated by a fast compiler.
  • Static Typing Where Possible, Dynamic Typing When Needed: the End of the Cold War Between Programming Languages

    Static Typing Where Possible, Dynamic Typing When Needed: the End of the Cold War Between Programming Languages

    Intended for submission to the Revival of Dynamic Languages Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between Programming Languages Erik Meijer and Peter Drayton Microsoft Corporation Abstract Advocates of dynamically typed languages argue that static typing is too rigid, and that the softness of dynamically lan- This paper argues that we should seek the golden middle way guages makes them ideally suited for prototyping systems with between dynamically and statically typed languages. changing or unknown requirements, or that interact with other systems that change unpredictably (data and application in- tegration). Of course, dynamically typed languages are indis- 1 Introduction pensable for dealing with truly dynamic program behavior such as method interception, dynamic loading, mobile code, runtime <NOTE to="reader"> Please note that this paper is still very reflection, etc. much work in progress and as such the presentation is unpol- In the mother of all papers on scripting [16], John Ousterhout ished and possibly incoherent. Obviously many citations to argues that statically typed systems programming languages related and relevant work are missing. We did however do our make code less reusable, more verbose, not more safe, and less best to make it provocative. </NOTE> expressive than dynamically typed scripting languages. This Advocates of static typing argue that the advantages of static argument is parroted literally by many proponents of dynami- typing include earlier detection of programming mistakes (e.g. cally typed scripting languages. We argue that this is a fallacy preventing adding an integer to a boolean), better documenta- and falls into the same category as arguing that the essence of tion in the form of type signatures (e.g.
  • Dynamic C++ Classes a Lightweight Mechanism to Update Code in a Running Program

    Dynamic C++ Classes a Lightweight Mechanism to Update Code in a Running Program

    The following paper was originally published in the Proceedings of the USENIX Annual Technical Conference (NO 98) New Orleans, Louisiana, June 1998 Dynamic C++ Classes A lightweight mechanism to update code in a running program Gísli Hjálmtÿsson AT&T Labs - Research Robert Gray Dartmouth College For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL:http://www.usenix.org/ Dynamic C++ Classes A lightweight mechanism to update code in a running program Gísli Hjálmtýsson Robert Gray AT&T Labs – Research Thayer School of Engineering1 180 Park Avenue Dartmouth College Florham Park, NJ 07932 Hanover, NH 03755 [email protected] [email protected] has transformed many industries, continuous change has Abstract become just as important as continuous operation. Techniques for dynamically adding new code to a run- Rapid introduction of new functionality and dynamic ning program already exist in various operating sys- adaptation to volatile needs is essential. Systems, par- tems, programming languages and runtime environ- ticularly telecommunications systems, must be custom- ments. Most of these systems have not found their way ized on a very fine time scale, either due to user demand 1 into common use, however, since they require pro- or to load and usage fluctuations. grammer retraining and invalidate previous software An effective way to allow both continuous operation investments. In addition, many of the systems are too and continuous change is through dynamic code up- high-level for performance-critical applications. This dates. New code is added to a running program without paper presents an implementation of dynamic classes halting the program, thus introducing new functionality for the C++ language.
  • Reprogramming Embedded Systems at Run-Time

    Reprogramming Embedded Systems at Run-Time

    Proceedings of the 8th International Conference on Sensing Technology, Sep. 2-4, 2014, Liverpool, UK Reprogramming Embedded Systems at Run-Time Richard Oliver, Adriana Wilde IEEE(S) and Ed Zaluska SMIEEE Electronics and Computer Science University of Southampton, United Kingdom {rjo2g10,agw106,ejz}@ecs.soton.ac.uk Abstract—The dynamic re-programming of embedded systems is load mechanisms. This paper aims to address the problem of a long-standing problem in the field. With the advent of wireless dynamic reprogramming of such systems, and will offer sensor networks and the ‘Internet of Things’ it has now become comparison and a critical appraisal of the methods currently necessary to be able to reprogram at run-time due to the being used in the field. difficulty of gaining access to such systems once deployed. The issues of power consumption, flexibility, and operating system The remainder of this paper is structured as follows. protections are examined for a range of approaches, and a Section II explains code execution on embedded devices, critical comparison is given. A combination of approaches is section III discusses various existing methods, focusing on the recommended for the implementation of real-world systems and issues of power consumption, flexibility of approach, and OS areas where further work is required are highlighted. protection. Section IV follows with conclusions and suggests future work in the area. Keywords-Wireless sensor networks; Programming; Runtime, Energy consumption II. BACKGROUND I. INTRODUCTION This section will cover the execution of code on microcontrollers. This is typically of no concern when flashing Embedded systems are pervasive in the modern world, a static image to a microcontroller but a greater understanding being found in systems as widely ranging as fridges, cars, is required to implement dynamic code loading.
  • Generalizing Loop-Invariant Code Motion in a Real-World Compiler

    Generalizing Loop-Invariant Code Motion in a Real-World Compiler

    Imperial College London Department of Computing Generalizing loop-invariant code motion in a real-world compiler Author: Supervisor: Paul Colea Fabio Luporini Co-supervisor: Prof. Paul H. J. Kelly MEng Computing Individual Project June 2015 Abstract Motivated by the perpetual goal of automatically generating efficient code from high-level programming abstractions, compiler optimization has developed into an area of intense research. Apart from general-purpose transformations which are applicable to all or most programs, many highly domain-specific optimizations have also been developed. In this project, we extend such a domain-specific compiler optimization, initially described and implemented in the context of finite element analysis, to one that is suitable for arbitrary applications. Our optimization is a generalization of loop-invariant code motion, a technique which moves invariant statements out of program loops. The novelty of the transformation is due to its ability to avoid more redundant recomputation than normal code motion, at the cost of additional storage space. This project provides a theoretical description of the above technique which is fit for general programs, together with an implementation in LLVM, one of the most successful open-source compiler frameworks. We introduce a simple heuristic-driven profitability model which manages to successfully safeguard against potential performance regressions, at the cost of missing some speedup opportunities. We evaluate the functional correctness of our implementation using the comprehensive LLVM test suite, passing all of its 497 whole program tests. The results of our performance evaluation using the same set of tests reveal that generalized code motion is applicable to many programs, but that consistent performance gains depend on an accurate cost model.
  • Efficient Symbolic Analysis for Optimizing Compilers*

    Efficient Symbolic Analysis for Optimizing Compilers*

    Efficient Symbolic Analysis for Optimizing Compilers? Robert A. van Engelen Dept. of Computer Science, Florida State University, Tallahassee, FL 32306-4530 [email protected] Abstract. Because most of the execution time of a program is typically spend in loops, loop optimization is the main target of optimizing and re- structuring compilers. An accurate determination of induction variables and dependencies in loops is of paramount importance to many loop opti- mization and parallelization techniques, such as generalized loop strength reduction, loop parallelization by induction variable substitution, and loop-invariant expression elimination. In this paper we present a new method for induction variable recognition. Existing methods are either ad-hoc and not powerful enough to recognize some types of induction variables, or existing methods are powerful but not safe. The most pow- erful method known is the symbolic differencing method as demonstrated by the Parafrase-2 compiler on parallelizing the Perfect Benchmarks(R). However, symbolic differencing is inherently unsafe and a compiler that uses this method may produce incorrectly transformed programs without issuing a warning. In contrast, our method is safe, simpler to implement in a compiler, better adaptable for controlling loop transformations, and recognizes a larger class of induction variables. 1 Introduction It is well known that the optimization and parallelization of scientific applica- tions by restructuring compilers requires extensive analysis of induction vari- ables and dependencies