We describe LLVM (low level virtual machine), a compiler framework designed to support transparent, lifelong program analysis and transformation for arbitrary programs, by providing high-level information to compiler transformations at compile-time, link-time, run-time, and in idle time between runs. LLVM defines a common, low-level code representation in static single assignment (SSA) form, with several novel features: a simple, language-independent type-system that exposes the primitives commonly used to implement high-level language features; an instruction for typed address arithmetic; and a simple mechanism that can be used to implement the exception handling features of high-level languages (and setjmp/longjmp in C) uniformly and efficiently. The LLVM compiler framework and code representation together provide a combination of key capabilities that are important for practical, lifelong analysis and transformation of programs. To our knowledge, no existing compilation approach provides all these capabilities. We describe the design of the LLVM representation and compiler framework, and evaluate the design in three ways: (a) the size and effectiveness of the representation, including the type information it provides; (b) compiler performance for several interprocedural problems; and (c) illustrative examples of the benefits LLVM provides for several challenging compiler problems.

/pdf/llvm-a-compilation-framework-for-lifelong-program-analysis-2e1wwcps42.pdf

LLVM: a compilation framework for lifelong program analysis & transformation

Author(s): Asanovic, K; Bodik, R; Catanzaro, B; Gebis, J; Husbands, P; Keutzer, K; Patterson, D; Plishker, W; Shalf, J; Williams, SW | Abstract: The recent switch to parallel microprocessors is a milestone in the history of computing. Industry has laid out a roadmap for multicore designs that preserves the programming paradigm of the past via binary compatibility and cache coherence. Conventional wisdom is now to double the number of cores on a chip with each silicon generation. A multidisciplinary group of Berkeley researchers met nearly two years to discuss this change. Our view is that this evolutionary approach to parallel hardware and software may work from 2 or 8 processor systems, but is likely to face diminishing returns as 16 and 32 processor systems are realized, just as returns fell with greater instruction-level parallelism. We believe that much can be learned by examining the success of parallelism at the extremes of the computing spectrum, namely embedded computing and high performance computing. This led us to frame the parallel landscape with seven questions, and to recommend the following: • The overarching goal should be to make it easy to write programs that execute efficiently on highly parallel computing systems • The target should be 1000s of cores per chip, as these chips are built from processing elements that are the most efficient in MIPS (Million Instructions per Second) per watt, MIPS per area of silicon, and MIPS per development dollar. • Instead of traditional benchmarks, use 13 “Dwarfs” to design and evaluate parallel programming models and architectures. (A dwarf is an algorithmic method that captures a pattern of computation and communication.) • “Autotuners” should play a larger role than conventional compilers in translating parallel programs. • To maximize programmer productivity, future programming models must be more human-centric than the conventional focus on hardware or applications. • To be successful, programming models should be independent of the number of processors. • To maximize application efficiency, programming models should support a wide range of data types and successful models of parallelism: task-level parallelism, word-level parallelism, and bit-level parallelism. 1 The Landscape of Parallel Computing Research: A View From Berkeley • Architects should not include features that significantly affect performance or energy if programmers cannot accurately measure their impact via performance counters and energy counters. • Traditional operating systems will be deconstructed and operating system functionality will be orchestrated using libraries and virtual machines. • To explore the design space rapidly, use system emulators based on Field Programmable Gate Arrays (FPGAs) that are highly scalable and low cost. Since real world applications are naturally parallel and hardware is naturally parallel, what we need is a programming model, system software, and a supporting architecture that are naturally parallel. Researchers have the rare opportunity to re-invent these cornerstones of computing, provided they simplify the efficient programming of highly parallel systems.

/pdf/the-landscape-of-parallel-computing-research-a-view-from-1i5pswggnf.pdf

The Landscape of Parallel Computing Research: A View from Berkeley

Julia: A Fresh Approach to Numerical Computing

This paper evaluates the suitability of the MapReduce model for multi-core and multi-processor systems. MapReduce was created by Google for application development on data-centers with thousands of servers. It allows programmers to write functional-style code that is automatically parallelized and scheduled in a distributed system. We describe Phoenix, an implementation of MapReduce for shared-memory systems that includes a programming API and an efficient runtime system. The Phoenix runtime automatically manages thread creation, dynamic task scheduling, data partitioning, and fault tolerance across processor nodes. We study Phoenix with multi-core and symmetric multiprocessor systems and evaluate its performance potential and error recovery features. We also compare MapReduce code to code written in lower-level APIs such as P-threads. Overall, we establish that, given a careful implementation, MapReduce is a promising model for scalable performance on shared-memory systems with simple parallel code

/pdf/evaluating-mapreduce-for-multi-core-and-multiprocessor-1xfheav61u.pdf

Evaluating MapReduce for Multi-core and Multiprocessor Systems

This paper shows that software pipelining is an effective and viable scheduling technique for VLIW processors. In software pipelining, iterations of a loop in the source program are continuously initiated at constant intervals, before the preceding iterations complete. The advantage of software pipelining is that optimal performance can be achieved with compact object code.This paper extends previous results of software pipelining in two ways: First, this paper shows that by using an improved algorithm, near-optimal performance can be obtained without specialized hardware. Second, we propose a hierarchical reduction scheme whereby entire control constructs are reduced to an object similar to an operation in a basic block. With this scheme, all innermost loops, including those containing conditional statements, can be software pipelined. It also diminishes the start-up cost of loops with small number of iterations. Hierarchical reduction complements the software pipelining technique, permitting a consistent performance improvement be obtained.The techniques proposed have been validated by an implementation of a compiler for Warp, a systolic array consisting of 10 VLIW processors. This compiler has been used for developing a large number of applications in the areas of image, signal and scientific processing.

/pdf/software-pipelining-an-effective-scheduling-technique-for-5boenfef8u.pdf

Software pipelining: an effective scheduling technique for VLIW machines

Combining is a local compiler optimization technique that can enhance the performance of global compaction techniques for VLIW machines. Given two adjacent operations of a certain class that are flow (read-after-write) dependent and that cannot be placed in the same micro-instruction, the combining technique can transform the operations so that the modified operations have no dependence. The transformed operations can be executed in the same micro-instruction, thus allowing the total execution time of the program to be reduced. In this paper, combining a pair of flow-dependent operations into a wide instruction word is suggested as an important compilation technique for VLIW architectures. Combining is particularly effective with software pipelining and loop unrolling since combinable operations can come together with a higher probability when these compilation techniques are used. We implemented combining in our parallelizing compiler for the wide instruction word architecture, which is now being built at the IBM T. J. Watson Research Center. It is shown that ten percent speedup is obtained on the Stanford integer benchmarks and other sequential-matured C programs, in comparison to compaction techniques that do not use combining. For a class of inner loops, combining can remove the inter-iteration dependencies completely and can improve performance in the same ratio as the loop is unrolled.

“Combining” as a compilation technique for VLIW architectures

We describe a new dynamic software scheduling technique for VLIW architectures, which compiles into VLIW code the program paths that are actually executed. Unlike trace processors, or DIF, the technique executes operations speculatively on multiple paths through the code, is resilient to branch mispredictions, and can achieve very large dynamic window sizes necessary for high ILP. Aggressive optimizations are applied to frequently executed portions of the code. Encouraging performance results were obtained on SPECint95 and TPC-C. The technique can be used for binary translation for achieving architectural compatibility with an existing processor, or as a VLIW scheduling technique in its own right.

/pdf/execution-based-scheduling-for-vliw-architectures-336g9m0lds.pdf

Execution-Based Scheduling for VLIW Architectures

In a computer capable of executing a superscalar and a very long instruction word instruction wherein the computer has compiled a number of primitive operations that can be executed in parallel into a single instruction having multiple parcels and each of the parcels correspond to an operation, the invention is an improved instruction cache to store all potential subsequent instructions and a method to select the subsequent instruction when several possible branches of execution are probable and must be evaluated. All branch conditions and all addresses of potential subsequent instructions of an instruction are replicated and stored in the instruction cache. All potential subsequent instructions are stored in the same block of the instruction cache having the same next address; individual instructions are identified by the replicated offset addresses. Further the instruction cache is divided into minicaches, each minicache to store one parcel, which allows rapid autonomous execution of each parcel. Simultaneously, all branch conditions are evaluated in parallel to determine the next instruction and all offset addresses are decoded in parallel. Only after the control flow or the branch taken, or the subsequent or next instruction is determined, are the results of that branch stored and the decoded addresses are used to late select the next instruction from the instruction cache.

Method and apparatus to select the next instruction in a superscalar or a very long instruction word computer having N-way branching

CPU overhead is minimized through tracking speculative exceptions (202) for later processing during exception resolution (204) including pointing to the addresses of these speculative instructions, and resolving (204) these exceptions by correcting (206) what caused the exception and re-executing (208) the instructions which are known to be in a taken path. Tracking speculative exceptions has two components which use an exception bit which is set in response to an exception condition (213). The invention tracks an original speculative exception which occurs when a speculative instruction whose operand(s) do not have any exception bits set encounters an exception condition. Speculative exception resolution is triggered when a non-speculative instruction - which is in the taken path of a conditional branch - uses an operand from a register having ist exception bit set. The presence of an exception condition and a non-speculative instruction yields an exception signal (220) to exception resolution (204). Speculative exception resolution (204) includes responding to output signals from the extra register and extra exception bit for correcting (204) the exception condition which caused the exception and re-executing (208) the instructions which depended on the results of the instructions causing the speculative exception.

Handling of exceptions in speculative instructions

A parallel hypervisor system for virtualizing application-specific supercomputers is disclosed. The hypervisor system comprises (a) at least one software-virtual hardware pair consisting of a software application, and an application-specific virtual supercomputer for accelerating the said software application, wherein (i) The virtual supercomputer contains one or more virtual tiles; and (ii) The software application and the virtual tiles communicate among themselves with messages; (b) One or more reconfigurable physical tiles, wherein each virtual tile of each supercomputer can be implemented on at least one physical tile, by configuring the physical tile to perform the virtual tile's function; and (c) A scheduler implemented substantially in hardware, for parallel pre-emptive scheduling of the virtual tiles on the physical tiles.

Kemal Ebcioglu

Papers

“Combining” as a compilation technique for VLIW architectures

Execution-Based Scheduling for VLIW Architectures

Method and apparatus to select the next instruction in a superscalar or a very long instruction word computer having N-way branching

Handling of exceptions in speculative instructions

Parallel hardware hypervisor for virtualizing application-specific supercomputers