Cooper K.Engineering a compiler

Chapter 6

Intermediate

Representations

6.1Introduction

In designing algorithms, a critical distinction arises between problems that must be solved online, and those that can be solved o ine. In general, compilers work o ine—that is, they can make more than a single pass over the code being translated. Making multiple passes over the code should improve the quality of code generated by the compiler. The compiler can gather information in one pass and use that information to make decisions in later passes.

The notion of a multi-pass compiler (see Figure 6.1) creates the need for an intermediate representation for the code being compiled. In translation, the compiler must derive facts that have no direct representation in the source code—for example, the addresses of variables and procedures. Thus, it must use some internal form—an intermediate representation or ir—to represent the code being analyzed and translated. Each pass, except the first, consumes ir. Each pass, except the last, produces ir. In this scheme, the intermediate representation becomes the definitive representation of the code. The ir must be expressive enough to record all of the useful facts that might be passed between phases of the compiler. In our terminology, the ir includes auxiliary tables, like a symbol table, a constant table, or a label table.

Selecting an appropriate ir for a compiler project requires an understanding of both the source language and the target machine, of the properties of programs that will be presented for compilation, and of the strengths and weaknesses of the language in which the compiler will be implemented.

Each style of ir has its own strengths and weaknesses. Designing an appropriate ir requires consideration of the compiler’s task. Thus, a source-to- source translator might keep its internal information in a form quite close to the source; a translator that produced assembly code for a micro-controller might use an internal form close to the target machine’s instruction set. It requires

133

Multi-pass compiler

Figure 6.1: The role of irs in a multi-pass compiler

consideration of the specific information that must be recorded, analyzed, and manipulated. Thus, a compiler for C might have additional information about pointer values that are unneeded in a compiler for Perl. It requires consideration of the operations that must be performed on the ir and their costs, of the range of constructs that must be expressed in the ir; and of the need for humans to examine the ir program directly.

(The compiler writer should never overlook this final point. A clean, readable external format for the ir pays for itself. Sometimes, syntax can be added to improve readability. An example is the symbol used in the iloc examples throughout this book. It serves no real syntactic purpose; however, it gives the reader direct help in separating operands from results.)

6.2Taxonomy

To organize our thinking about irs, we should recognize that there are two major axes along which we can place a specific design. First, the ir has a structural organization. Broadly speaking, three di erent organizations have been tried.

•Graphical irs encode the compiler’s knowledge in a graph. The algorithms are expressed in terms of nodes and edges, in terms of lists and trees. Examples include abstract syntax trees and control-flow graphs.

•Linear irs resemble pseudo-code for some abstract machine. The algorithms iterate over simple, linear sequences of operations. Examples include bytecodes and three-address codes.

•Hybrid irs combine elements of both structural and linear irs, with the goal of capturing the strengths of both. A common hybrid representation

uses a low-level linear code to represent blocks of straight-line code and a graph to represent the flow of control between those blocks.1

The structural organization of an ir has a strong impact on how the compiler writer thinks about analyzing, transforming, and translating the code. For example, tree-like irs lead naturally to code generators that either perform a

1We say very little about hybrid irs in the remainder of this chapter. Instead, we focus on the linear irs and graphical irs, leaving it to the reader to envision profitable combinations of the two.

tree-walk or use a tree pattern matching algorithm. Similarly, linear irs lead naturally to code generators that make a linear pass over all the instructions (the “peephole” paradigm) or that use string pattern matching techniques.

The second axis of our ir taxonomy is the level of abstraction used to represent operations. This can range from a near-source representation where a procedure call is represented in a single node, to a low-level representation where multiple ir operations are assembled together to create a single instruction on the target machine.

To illustrate the possibilities, consider the di erence between the way that a source-level abstract syntax tree and a low-level assembly-like notation might represent the reference A[i,j] into an array declared A[1..10,1..10]).

In the source-level ast, the compiler can easily recognize that the computation is an array reference; examining the low-level code, we find that simple fact fairly well obscured. In a compiler that tries to perform data-dependence analysis on array subscripts to determine when two di erent references can touch the same memory location, the higher level of abstraction in the ast may prove valuable. Discovering the array reference is more di cult in the low-level code; particularly if the ir has been subjected to optimizations that move the individual operations to other parts of the procedure or eliminate them altogether. On the other hand, if the compiler is trying to optimize the code generated for the array address calculation, the low-level code exposes operations that remain implicit in the ast. In this case, the lower level of abstraction may result in more e cient code for the address calculation.

The high level of abstraction is not an inherent property of tree-based irs; it is implicit in the notion of a syntax tree. However, low-level expression trees have been used in many compilers to represent all the details of computations, such as the address calculation for A[i,j]. Similarly, linear irs can have relatively highlevel constructs. For example, many linear irs have included a mvcl operation2 to encode string-to-string copy as a single operation.

On some simple Risc machines, the best encoding of a string copy involves clearing out the entire register set and iterating through a tight loop that does a multi-word load followed by a multi-word store. Some preliminary logic is needed to deal with alignment and the special case of overlapping strings. By

2The acronym is for move character long, an instruction on the ibm 370 computers.

using a single ir instruction to represent this complex operation, the compiler writer can make it easier for the optimizer to move the copy out of a loop or to discover that the copy is redundant. In later stages of compilation, the single instruction is expanded, in place, into code that performs the copy or into a call to some system or library routine that performs the copy.

Other properties of the ir should concern the compiler writer. The costs of generating and manipulating the ir will directly e ect the compiler’s speed. The data space requirements of di erent irs vary over a wide range; and, since the compiler typically touches all of the space that is allocated, data-space usually has a direct relationship to running time. Finally, the compiler writer should consider the expressiveness of the ir—its ability to accommodate all of the facts that the compiler needs to record. This can include the sequence of actions that define the procedure, along with the results of static analysis, profiles of previous executions, and information needed by the debugger. All should be expressed in a way that makes clear their relationship to specific points in the ir.

6.3Graphical IRs

Many irs represent the code being translated as a graph. Conceptually, all the graphical irs consist of nodes and edges. The di erence between them lies in the relationship between the graph and the source language program, and in the restrictions placed on the form of the graph.

6.3.1Syntax Trees

The syntax tree, or parse tree, is a graphical representation for the derivation, or parse, that corresponds to the input program. The following simple expression grammar defines binary operations +, −, ×, and ÷ over the domain of tokens number and id.

Goal

The syntax tree on the right shows the derivation that results from parsing the expression x × 2 + x × 2 × y. This tree represents the complete derivation, with

a node for each grammar symbol (terminal or non-terminal) in the derivation. It provides a graphic demonstration of the extra work that the parser goes through to maintain properties like precedence. Minor transformations on the grammar can reduce the number of non-trivial reductions and eliminate some of these steps. (See Section 3.6.2.) Because the compiler must allocate memory for the nodes and edges, and must traverse the entire tree several times, the compiler writer might want to avoid generating and preserving any nodes and edges that are not directly useful. This observation leads to a simplified syntax tree.

6.3.2Abstract Syntax Tree

The abstract syntax tree (ast) retains the essential structure of the syntax tree, but eliminates the extraneous nodes. The precedence and meaning of the expression remain, but extraneous nodes have disappeared.

,,+PPPPqP

× ×

x ,, @R@2 × ,, @R@ y x ,, @@R2

Abstract syntax tree for x × 2 + x × 2 × y

The ast is a near source-level representation. Because of its rough correspondence to the parse of the source text, it is easily built in the parser.

Asts have been used in many practical compiler systems. Source-to-source systems, including programming environments and automatic parallelization tools, generally rely on an ast from which the source code can be easily regenerated. (This process is often called “pretty-printing;” it produces a clean source text by performing an inorder treewalk on the ast and printing each node as it is visited.) The S-expressions found in Lisp and Scheme implementations are, essentially, asts.

Even when the ast is used as a near-source level representation, the specific representations chosen and the abstractions used can be an issue. For example, in the Rn Programming Environment, the complex constants of Fortran programs, written (c1,c2), were represented with the subtree on the left. This choice worked well for the syntax-directed editor, where the programmer was able to change c1 and c2 independently; the “pair” node supplied the parentheses and the comma.