A Framework for Incremental Extensible Compiler Construction

  • Published on
    06-Aug-2016

  • View
    220

  • Download
    7

Embed Size (px)

Transcript

  • International Journal of Parallel Programming, Vol. 32, No. 4, August 2004 ( 2004)

    A Framework for IncrementalExtensible Compiler Construction

    Steven Carroll1,3 and Constantine Polychronopoulos2

    Received December 9, 2003; revised January 13, 2004; accepted March 15, 2004

    Extensibility in complex compiler systems goes well beyond modularity ofdesign and it needs to be considered from the early stages of the design,especially the design of the Intermediate Representation. One of the primarybarriers to compiler pass extensibility and modularity is interference betweenpasses caused by transformations that invalidate existing analysis information.In this paper, we also present a callback system which is provided to auto-matically track changes to the compilers internal representation (IR) allowingfull pass reordering and an easy-to-use interface for developing lazy updateincremental analysis passes. We present a new algorithm for incremental in-terprocedural data ow analysis and demonstrate the benets of our designframework and our prototype compiler system. It is shown that compilationtime for multiple data ow analysis algorithms can be cut in half by incre-mentally updating data ow analysis.

    KEY WORDS: Compiler construction; incremental compilation.

    1. INTRODUCTION

    Compiler design concerns both the effectiveness of the analysis and codeoptimization methods as well as the efciency of the compilation processitself. The latter has been the subject of research (along with compileroptimization algorithms) primarily with respect to the complexity of indi-vidual analysis or optimization algorithms. However, a global approach to

    1 Microsoft Corporation, 1 Microsoft Way, Redmond, WA 98052, USA. E-mail: scarroll@microsoft.com.

    2 Center for Supercomputing Research and Development, University of Illinois, 1308 W.Main, Urbana-Champaign IL 61801, USA. E-mail: cdp@csrd.uiuc.edu

    3 To whom correspondence should be addressed.

    289

    0885-7458/04/0800-0289/0 2004 Plenum Publishing Corporation

  • 290 Carroll and Polychronopoulos

    compiler efciency that considers the entire ensemble of analysis and opti-mization passes is a considerably more complex subject that has attractedmuch less attention by the research community.

    The complexity of compiler systems, especially those that include pro-gram restructuring and code optimization for microarchitectures that sup-port instruction level parallelism (ILP), is such that their developmenttime and, correspondingly, their life-cycle far outlast the life-cycle of pro-cessors and computer systems. Typical production compilers represent, ata minimum, tens of man-years of development effort. It is typical toexpect a plethora of enhancements to a commercial compiler, includingnew optimizations, revisions of existing modules, extensions to the internalrepresentation (IR), interfacing with DLLs and multithreading libraries,extensions that are necessary to facilitate porting to various architectures,etc. Leveraging powerful restructuring (and optimizing) compilers acrossprocessor and system generations is the norm and the large life-cycleof a compiler almost guarantees that the original developers are neverthose performing the majority of modications, extensions and mainte-nance. Arguably the most commonly used and extended compiler is gcc,which has been modied and ported to a variety of systems since 1987(or presently 16 years).(1) The result of the various modications andre-adaptations of a typical compiler over the years is, more often than not,patchwork code that reuses old modules in new contexts and adapts oldcompilers to work with new language idioms and machine architectures.

    In this paper, we present a compiler design framework that facilitatesthree main goals: (1) extensibility, (2) compilation efciency, and (3) codeoptimization. We present our design approach and show that designingfor extensibility also improves code optimization and dramatically reducescompilation time.

    Our extensible compiler prototype is PROMIS(2) which is a multilin-gual parallelizing compilation system targeting a host of RISC and CISCarchitectures, including MIPS and x86 ISAs. One of the goals of thePROMIS project is to develop a compiler framework that allows compilerresearchers to develop new analyses and transformations for new architec-tures without deep knowledge of the underlying IR, data ow and com-mon optimization passes. A library of common passes is provided thatthe compiler developer can deploy in any order without any chance ofinterference from new passes.4 In this paper, we present an overview ofour design methodology, describe the implementation of specic analy-ses and optimization passes that take advantage of the extensibility fea-tures, and discuss experiments that clearly demonstrate the advantages of

    4The PROMIS source code can be downloaded at http://promis.csrd.uiuc.edu/.

  • A Framework for Incremental Extensible Compiler Construction 291

    the proposed design framework. Eventhough many of the advantages andbenets are of a qualitative nature, our experiments provide strong quan-titative evidence about the benets of our framework with respect to dra-matic reduction in compilation time.

    In Section 2, we will present background on incremental analysis andthe PROMIS IR. Next, in Section 3, we present the architecture of thecallback mechanism and the API for simplifying incremental algorithmdesign. In Section 4, we describe our implementation of a self-maintain-ing data ow analysis. In Section 5, we present quantitative evaluations ofthe benets of this technique in terms of compile time improvement andease of implementation. Finally, we present related work, future work, andconclusions.

    2. BACKGROUND AND OVERVIEW

    Throughout the paper we use the terms pass, transformations, opti-mization, and module interchangeably to indicate an implementation ofan analysis or optimization pass. In the case of our prototype compiler,PROMIS, a pass can be any module that involves a total or partial walkthrough the IR and results in either transforming the IR or gathering dataor control ow (CF) information about the target program.

    We consider passes to be of one of two categories: analysis passesor transformation/optimization passes. Many traditional compiler mod-ules can be broken into an analysis pass and a transformation pass. Forinstance, the common subexpression elimination (CSE) pass rst calculateswhich subexpressions are available at each point in the program. That partof the original pass is called the available expression analysis pass. Next,the CSE transformation pass uses the available expression analysis infor-mation to replace the common subexpressions with copies.

    Frequently, analysis information is used multiple times throughout acomplete compilation. For instance, CSE creates new copies that can becopy propagated, which in turn creates more opportunities for CSE. How-ever, any transformation pass that runs in-between the initial calculationof the analysis information and a reuse of that analysis information, canpotentially modify the program, thereby invalidating the analysis. If thisoccurs, it would be necessary to recalculate the analysis information ormodify the transformation to maintain the analysis information. Since itwould be impossible for the designers of the libraries in PROMIS to pre-dict all possible orderings and new passes that could be added to the sys-tem, it would be necessary for the users conguration of PROMIS toeither recalculate needed analysis every time a transformation pass occursor modify the library code to maintain the information. The former is

  • 292 Carroll and Polychronopoulos

    inefcient and the latter requires the compiler writer to modify unfamiliarcode.

    The Extensible Compiler Interface (ECI) feature of PROMIS attemptsto address these problems. It provides an API that allows passes to trackthe changes in the IR transparently and independently from the transfor-mation passes using a callback mechanism. Analysis passes can update thestate of their analysis information using the changes recorded by the callbacks and incremental algorithms. Incremental algorithms are algorithmswhere the state can be updated to reect changes in the input. Order ofmagnitude improvements in compile time have been observed(3) throughincremental compilation. In this paper, we present a novel organization fora compiler that signicantly improves the modularity and extensibility of acompiler. In addition, the ECI framework provides novel support to easethe job of designing incremental algorithms, which have been notoriouslydifcult to implement and maintain.

    2.1. PROMIS IR

    The basics of the PROMIS IR are presented here to the extent nec-essary to understand the algorithms below. The PROMIS IR is based ona modied Hierarchical Task Graph (HTG).(2) The details of the IR canbe found at the PROMIS web site.(4) The HTG has two kinds of nodes,Statement nodes and Compound nodes. Statement nodes are the simplestatements that make up the program like Call statements, Assignmentstatements, Pointer statements and Branch statements. Compound nodesare nodes that contain other nodes. For instance, Loop nodes containsubnodes that represent the body of that loop. Each Loop node has animplicit back edge that connects the end of the body with its beginning.Hierarchical basic blocks are similar to basic blocks in that they containconsecutive nodes without branches. However, the consecutive nodes canbe compound nodes that contain branches within them. Figure 1 depictsan HTG. The outermost rectangle is the function block, which is theroot of the HTG. Ovals represent the loop nodes.

    The HTGs nodes are connected by two kinds of arcs: control ow(CF) arcs and data dependence (DD) arcs. The CF arcs are always presentand the DD arcs can be constructed if desired. The HTG nodes and thetwo types of arcs form the Core IR. All transformation passes are requiredto maintain the Core IR structures.

    In order to improve the extensibility of the PROMIS compiler, sev-eral mechanisms are provided for adding new instructions, types, expres-sions and analysis information. For this paper, we will focus on how toadd new analysis information to the IR. New analysis information called

  • A Framework for Incremental Extensible Compiler Construction 293

    Function block

    Hier. basic blocksStatement

    Loop Node

    Branch node

    Fig. 1. Hierarchical task graph example.

    External Data Structures (EDSs) can be attached to any data structurein the IR. For example, data ow information can be attached to eachstatement node. An EDS attached to a variable can describe whether thatvariable is privatizable. They are equivalent to annotations in the SUIFcompiler.(5)

    3. ARCHITECTURE

    There are two layers to the ECI architecture in PROMIS. The lowestlevel consists of the callbacks that are invoked on each modication to theIR. This level provides maximum exibility to developers of new passes. Inaddition, there is an API built on top of the raw callback level that pro-vides commonly needed functionality for incremental analysis described inSections 3.2 and 3.3. It improves ease-of-use at the cost of some generality.

    3.1. Callbacks

    Callback functions can be registered for a number of different eventsin the IR. When an event occurs, all callbacks registered for that eventare invoked with all relevant parameters. For instance, when a new CFarc is added, the add Control Flow Arc callbacks are invoked with thenew CF arc as a parameter. Since all modications to the IR go througha protected API, all transformations to the IR will transparently triggerthe appropriate callbacks.

  • 294 Carroll and Polychronopoulos

    The minimum set of callbacks necessary to track changes to a pro-gram in the PROMIS IR is node addition and removal, and CF arc addi-tion and removal. The node addition and removal callbacks track not onlywhen new nodes are added or existing nodes are removed, but also whenexisting nodes are modied. For instance, if a statement node contains theexpression x = 3 + 3 and it is transformed into x = 6 by constant fold-ing, this modication triggers one node removal and one node additioncallback. Correctness is assured because any change to an existing nodeis equivalent to the removal of that node and the addition of a new nodewith the new expression.

    However, tracking node addition and deletion is not sufcient totrack all meaningful changes to a program. In order to track so-calledstructural changes, the control ow arcs must also be tracked. A struc-tural change is any change to the IR that can potentially change basicblock boundaries or the program ordering of those basic blocks. Remov-ing a branch with a constant branch condition would be one example ofa transformation that structurally modies a program, as would functioninlining. The addition or removal of call statements is another example(although these do not require CF arc tracking to detect).

    The callbacks presented so far are sufcient to track any change inthe program, but a larger set of callbacks is provided to make incremen-tal analysis more convenient and efcient. For instance, any new variablesadded to the IR can be detected by examining new nodes and modi-cations of nodes, but we also provide a callback for variable creation tomake those events easier to track.

    3.2. Event Queues

    The callbacks are sufcient to maintain any type of analysis sincethey can track any change to the IR, but there is a lot of overlap inneeded functionality for good incremental algorithms. For instance, it isalways best to postpone updating the analysis information until that infor-mation is actually queried. This lazy update scheme ensures that valu-able compilation time is not wasted updating analysis that will never beused. In this subsection, we present the various APIs that are providedto the compiler developer for managing the changes to the IR. Each ofthese interfaces is implemented as a set of pre-written callbacks that canbe registered for a new analysis pass. When the developer instantiates oneof these structures, the callbacks are automatically registered, presenting asimple interface to access change information.

    The simplest interface is a dirty ag. The dirty ag is set if anyof a list of provided modication types occur (i.e., CF arcs, nodes, or

  • A Framework for Incremental Extensible Compiler Construction 295

    combinations). This interface is useful if the developer of the new pass isinterested in whether or not the IR has been modied, but is not inter-ested in how it was modied. A rst step for a new analysis might be tosimply use the dirty ag to determine if the IR has changed since the ini-tial calculation and then recalculate if necessary.

    However, if a compiler developer wants to develop an incremen-tal analysis pass, one available interface is the Event Queue. An EventQueue is simply a list of recorded modications to the IR in the orderin which they occurred. An event in our system is a triple of the form{type,action,id}. type identies what t...

Recommended

View more >