Cooper K.Engineering a compiler

Figure B.7: Two-dimensional, hashed, symbol table

The two-dimensional table, shown in Figure B.7, uses two distinct hash index tables. The first, shown along the left edge of the drawing, corresponds to the sparse index table from Figure B.3. The implementation uses this table to hash on symbol name. The second, shown along the top of the drawing, is a hash table for field-names. The programmer references individual fields by both their textual name and the name of the symbol; the implementation hashes a the symbol name to obtain an index and the field name to select a vector of data. The desired attribute is stored in the vector under the symbol’s index. It behaves as if each field has its own hash table, implemented as shown in Figure B.3.

While this seems complex, it is not particularly expensive. Each table access requires two hash computations rather than one. The implementation need not allocate storage for a given field until a value is stored in the field; this avoids the space overhead of unused fields. It allows individual developers to create and delete symbol table fields without interfering with other programmers.

Our implementation provided entry points for setting initial values for a field (by name), for deleting a field (by name), and for reporting statistics on field use. This scheme allows individual programmers to manage their own symbol table use in a responsible and independent way, without interference from other programmers and their code.

As a final issue, the implementation should be abstracted with respect to a specific symbol table. That is, it should always take a table instance as a parameter. This allows the compiler to reuse the implementation in many cases. For example, a well-written set of symbol table routines greatly simplifies the implementation of value numbering, using either the classic algorithm for single

blocks or Simpson’s scc algorithm for entire procedures.

cfl context-free language

csl context-sensitive language

csg context-sensitive grammar

definition the point in the code where a value is defined; in common use, it refers to the operation whose evaluation creates the value. (See also use).

degree used, with reference to a node in a graph, as the number of edges that connect to that node. In the text, the degree of a node n is sometimes denoted n◦, using a notation due to the Babylonians.

dfa deterministic finite automaton

dg data dependence graph

dope vector The vector of information passed at a call site to describe an array and its dimensions. The vector contains the ”inside dope” on the array—a late fifties slang term.

fa finite automaton – used to refer, without bias, to either a dfa or an nfa

fp frame pointer – see arp. The term “frame” refers to a “stack frame”. Activation records that are kept on the run-time stack are sometimes called stack frames. This abbreviation should not occur in the text. If it does, please report it to eac@cs.rice.edu.

heuristic a rule used to guide some complex process. Heuristic techniques are often used to approximate the solution of an instance of some np-complete problem.

A classic heuristic for whitewater canoeing is ”don’t hit rocks and don’t fall out of the boat.” The amateur who follows this heuristic improves the chances of survival for both canoeist and canoe.

il intermediate language (or intermediate representation) See Chapter 6.

instruction the collection of operations that are issued in the same cycle.

ir intermediate representation (or intermediate language) See Chapter 6.

iloc Intermediate language for an optimizing compiler – the low-level intermediate language used in most of the examples in this book. See Appendix A).

interval graph need a good definition

lr(1) a popular, bottom-up, deterministic parsing technique. The name derives from the fact that the parser makes a left-to right scan while building a reverse rightmost derivation using a lookahead of at most 1 symbol.

nfa non-deterministic finite automaton

355

np-complete A specific class of problems in the hierarchy of computational complexity. It is an open question whether or not deterministic polynomialtime algorithms exist for these problems. If a deterministic polynomialtime algorithm exists for any of these problems, one exists for all of these problems. See a good text on algorithms, such as Cormen et al. [27] for a deeper discussion of this issue.

In practical, compiler-related terms, the only known algorithms that guarantee optimal solutions to instances of an np-complete problem require O(2n) time, where n is some measure of the problem size. Compilers must approximate solutions to several np-complete problems, including the realistic versions of register allocation and instruction scheduling.

ool object-oriented language

oop object-oriented programming

operation an indivisible unit of work performed by one functional unit on a modern processor. Examples include loading or storing a value, adding two registers, or taking a branch.

re regular expression – a notation used to describe a regular language. See Section 2.2.

rom read-only memory – used to describe several types of non-volatile memory where the contents are immutable. In common use, it refers to a semiconductor memory with predetermined contents. The term is also used to refer to the contents of a compact disc (cd-rom) or a digital video disk (dvd-rom).

tos top of stack – For many languages, a stack discipline can be used to allocate activation records. (See Chapters 7 and 8.) The tos is a pointer to the current location of the extendable end of the stack. If the compiler needs to generate code that extends the current ar, it needs a pointer to tos in addition to the arp.

use a reference that uses some value, usually as an operand to some operation. In common use, the term refers to the point in the code where the reference occurs. (See also definition.)

The Impact of Naming, 149

The Perils of Poor Hash Functions, 344

What about Context-Sensitive Grammars?, 127

What About Out-of-Order Execution?, 304

Garbage collection, 197

Graph Coloring, 267

Hash Table

Open hashing, 344

Hash Table, Bucket hashing, 344

Hash tables

Implementation, 341

Interference, 269

Interference graph, 269

Interpreter, 2

Live-range splitting, 273

Memory model

Memory-to-memory, 150, 254

Register-to-register, 150, 254

Nondeterministic finite automata (nfa), 30

Reference counting, 196

Regular expression, 22

Short-circuit evaluation, 219

Static distance coordinate, 158

Unambiguous value, 207

[10]David Bernstein, Dina Q. Goldin, Martin C. Golumbic, Hugo Krawczyk, Yishay Mansour, Itai Nahshon, and Ron Y. Pinter. Spill code minimization techniques for optimizing compilers. SIGPLAN Notices, 24(7):258–263, July 1989. Proceedings of the ACM SIGPLAN ’89 Conference on Programming Language Design and Implementation.

[11]Robert L. Bernstein. Producing good code for the case statement.

Software—Practice and Experience, 15(10):1021–1024, October 1985.

[12]Andrew Binstock and John Rex. Practical Algorithms for Programmers. Addison-Wesley Publishing Company, Reading, Massachusetts, 1995.

[13]Preston Briggs. Register Allocation via Graph Coloring. PhD thesis, Rice University, April 1992.

[14]Preston Briggs, Keith D. Cooper, and L. Taylor Simpson. Value numbering. Software–Practice and Experience, 00(00), June 1997. Also available as a Technical Report From Center for Research on Parallel Computation, Rice University, number 95517-S.

[15]Preston Briggs, Keith D. Cooper, and Linda Torczon. Coloring register pairs. ACM Letters on Programming Languages and Systems, 1(1):3–13, March 1992.

[16]Preston Briggs, Keith D. Cooper, and Linda Torczon. Rematerialization.

SIGPLAN Notices, 27(7):311–321, July 1992. Proceedings of the ACM SIGPLAN ’92 Conference on Programming Language Design and Implementation.

[17]Preston Briggs, Keith D. Cooper, and Linda Torczon. Improvements to graph coloring register allocation. ACM Transactions on Programming Languages and Systems, 16(3):428–455, May 1994.

[18]Michael Burke and Linda Torczon. Interprocedural optimization: Eliminating unnecessary recompilation. ACM Transactions on Programming Languages and Systems, 15(3):367–399, July 1993.

[19]David Callahan and Brian Koblenz. Register allocation via hierarchical graph coloring. SIGPLAN Notices, 26(6):192–203, June 1991. Proceedings of the ACM SIGPLAN ’91 Conference on Programming Language Design and Implementation.

[20]Gregory J. Chaitin. Register allocation and spilling via graph coloring.

SIGPLAN Notices, 17(6):98–105, June 1982. Proceedings of the ACM SIGPLAN ’82 Symposium on Compiler Construction.

[21]Gregory J. Chaitin. Register allocation and spilling via graph coloring. United States Patent 4,571,678, February 1986.