Cooper K.Engineering a compiler

The register allocator could rewrite this to use only two registers (plus rarp):

The allocator cannot fit all of x, y, and x + 2 × y into two registers. As written, the code preserves x and not y.

Of course, evaluating the right child first is not a general solution. For the expression 2 × y + x, the appropriate rule is “left child first.” Some expressions, such as x + (5 + y) × 7 defy a static rule. The best evaluation order for limiting register use is 5 + y, then × 7, and finally + x. This requires alternating between right and left children.

To choose the correct evaluation order for subtrees of an expression tree, the compiler needs information about the details of each subtree. To minimize register use, the compiler should first evaluate the more demanding subtree— the subtree that needs the most registers. The code must must preserve the value computed first across the evaluation of the second subtree; thus, handling the less demanding subtree first increases the demand for registers in the more demanding subtree by one register. Of course, determining which subtree needs more registers requires a second pass over the code.

This set of observations leads to the Sethi-Ullman labeling algorithm (see Section 9.1.2). They also make explicit the idea that taking a second pass over an expression tree can lead to better code than the compiler can generate in a single pass [31]. This should not be surprising; the idea is the basis for multipass compilers. An obvious corollary suggests that the second and subsequent passes should know how large to make data structures such as the symbol table.

Accessing Parameter Values The treewalk code generator implicitly assumes that a single access method works for all identifiers. Names that represent formal parameters may need di erent treatment. A call-by-value parameter passed in the ar can be handled as if it were a local variable. A call-by-reference parameter passed in the ar requires one additional indirection. Thus, for the call-by-reference parameter x, the compiler might generate

Digression: Generating loadAI instructions

A careful reader might notice that the code in Figure 8.2 never generates iloc’s loadAI instruction. In particular, it generates the sequence

when the operation loadAI rarp,@x r2 achieves the same e ect with one fewer register and one fewer instruction.

Throughout the book, we have assumed that it is preferable to generate this two operation sequence rather than the single operation. Two reasons dictate this choice:

1.The longer code sequence gives a register name to the label @x. If the label is reused in contexts other than a loadAO instruction, having an explicit name is useful. Since @x is typically a small integer, this may occur more often than you would expect.

2.The two instruction sequence leads to a clean functional decomposition in the code generator, as seen in Figure 8.2. Here, the code uses two routines, base and o set, to hide the details of addressability. This interface lets base and o set hide any data structures that they use.

Subsequent optimization can easily convert the two instruction sequence into a single loadAI if the constant o set is not reused. For example, a graphcoloring register allocator that implements rematerialization will do this conversion if the intermediate register is needed for some other value.

If the compiler needs to to generate the loadAO directly, two approaches make sense. The compiler writer can pull the case logic contained in base and o set up into the case for IDENTIFIER in Figure 8.2. This accomplishes the objective, at the cost of less clean and modular code. Alternatively, the compiler writer can have emit maintain a small instruction bu er and perform peephole-style optimization on instructions as they are generated (see Section 15.2). Keeping the bu er small makes this practical. If the compiler follows the “more demanding subtree first” rule, the o set will be generated immediately before the loadAO instruction. Recognizing a loadI that feeds into a loadAO is easy in the peephole paradigm.

to obtain x’s value. The first two operations move the memory address of the parameter’s value into r2. The final operation moves that value into r3.

Many linkage conventions pass the first few parameters in registers. As written, the code in Figure 8.2 cannot handle a value that is permanently kept in a register. The necessary extension, however, is simple.

For call-by-value parameters, the IDENTIFIER case must check if the value is already in a register. If so, it assigns the register number to result. Otherwise, it uses the code to load the value from memory. It is always safe to keep call- by-value parameters in a register in the procedure where they are declared.

For a call-by-reference parameter that is passed in a register, the compiler only needs to emit the single operation that loads the value from memory. The value, however, must reside in memory across each statement boundary, unless the compiler can prove that it is unambiguous—that is, not aliased. This can require substantial analysis.

Function Calls in an Expression So far, we have assumed that the basic operands in an expression are variables and temporary values produced by other subexpressions. Function calls also occur as references in expressions. To evaluate a function call, the compiler simply generates the calling sequence needed to invoke the function (see Section 7.6 and 8.9) and emits the code necessary to move the returned value into a register. The procedure linkage limits the impact on the calling procedure of executing the function.

The presence of a function call may restrict the compiler’s ability to change the expression’s evaluation order. The function may have side e ects that modify the value of variables used in the expression. In that situation, the compiler must adhere strictly to the source language’s evaluation order; without side effects, the compiler has the freedom to select an evaluation order that produces better code. Without knowledge about the possible side e ects of the call, the compiler must assume the worst case—that the function call results in a modification to every variable that the function could possible touch. The desire to improve on “worst case” assumptions such as this motivated much of the early work in interprocedural data-flow analysis (see Section 13.4).

Other Arithmetic Operations To handle additional arithmetic operations, we can extend our simple model. The basic scheme remains the same: get the operands into registers, perform the operation, and store the result if necessary. The precedence encoded in the expression grammar ensures the intended ordering. Unary operators, such as unary minus or an explicit pointer dereference, evaluate their sole subtree and then perform the specified operation. Some operators require complex code sequences for their implementation (i.e., exponentiation, trigonometric functions, and reduction operators). These may be expanded directly inline, or they may be handled with a function call to a library supplied by the compiler or the operating system.

Mixed-type Expressions One complication allowed by many programming languages is an operation where the operands have di erent types. (Here, we are concerned primarily with base types in the source language, rather than programmer-defined types.) Consider an expression that multiplies a floatingpoint number by an integer. First, and foremost, the source language must define the meaning of such a mixed-type expression. A typical rule converts both operands to the more general type, performs the operation in the more

Explicitly representing x < y with a number makes this ine cient.

This sequence can be cleaned up. The compiler should combine the conditional branches used to evaluate x < y with the corresponding branches that select either statement1 or statement2. This avoids executing redundant branches. It eliminates the need to instantiate a value (true or false) as the result of evaluating x < y. With a little thought, the compiler writer can ensure that the compiler generates code similar to this:

Here, the overhead of evaluating x < y has been folded into the overhead for selecting between statement1 and statement2. Notice that the result of x < y has no explicit value; its value is recorded implicitly—essentially in the processor’s program counter as it executes either the statement at L1 or L2.

Positional Encoding The previous example encodes the expression’s value as a position in the program. We call this representation a positional encoding. To see the strengths of positional encoding, consider the code required to evaluate the expression a<b or c<d and e<f. A naive code generator might emit:

Notice that this code only evaluates as much of the expression as is required to determine the final value.

With some instruction sets, positional encoding of relational expressions makes sense. Essentially, it is an optimization that avoids assigning actual values to the expression until an assignment is required, or until a boolean operation is performed on the result of the expression. Positional encoding represents the expression’s value implicitly in the control-flow path taken through the code. This allows the code to avoid some instructions. It provides a natural framework for improving the evaluation of some boolean expressions through a technique called short circuit evaluation. On an architecture where the result of a comparison is more complex than a boolean value, positional encoding can seem quite natural.

The compiler can encode booleans in the same way. A control-flow construct that depends on the controlling expression (w < x y < z) might be implemented entirely with a positional encoding, to avoid creating boolean values that represent the results of the individual comparisons. This observation leads to the notion of short-circuit evaluation for a boolean expression—evaluating only as much of the expression as is required to determine its value. Short circuiting relies on two boolean identities:

x, false x = false

x, true x = true

Some programming languages, like c, require the compiler to generate code for short-circuit evaluation. For example, the c expression

(x != 0 && y/x > 0.001)

relies on short-circuit evaluation for safety. If x is zero, y/x is not defined. Clearly, the programmer intends to avoid the hardware exception triggered for division by zero. The language definition specifies that this code will never perform the division if x has the value zero.

The real issue is implicit versus explicit representation. Positional encoding of an operation, for example, only makes sense when both of the operands are positionally encoded. If either operand is represented by a numerical value, using the hardware operation makes more sense. Thus, positional encoding

occurs most often when evaluating an expression whose arguments are produced by other operations (relationals) and whose result is not stored.

8.4.2Hardware Support for Relational Expressions

A number of specific, low-level details in the instruction set of the target machine strongly influence the choice of a representation for relational values. In particular, the compiler writer must pay attention to the handling of condition codes, compare operations, and conditional move operations, as they have a major impact on the relative costs of the various representations. We will consider four di erent instruction-level schemes for supporting relational comparisons. Each scheme is an idealized version of a real implementation.

Straight Condition Codes In this scheme, the comparison operation sets a condition code register. The only instruction that interprets the condition code is a conditional branch, with variants that branch on each of the six relations (<, ≤, =, ≥, >, and =).

This model forces the compiler to use conditional branches for evaluating relational expressions. If the result is used in a boolean operation or is preserved in a variable, the code converts it into a numerical representation of a boolean. If the only use of the result is to determine control flow, the conditional branch that “reads” the condition code can usually implement the source-level controlflow construct, as well. Either way, the code has at least one conditional branch per relational operator.

The strength of condition-codes comes from another feature that processors usually implement alongside the condition codes. Typically, these processors have arithmetic operations that set the condition code bits to reflect their computed results. If the compiler can arrange to have the arithmetic operations, which must be performed, set the condition code appropriately, then the comparison operation can be omitted. Thus, advocates of this architectural style argue that it allows a more e cient encoding of the program—the code may execute fewer instructions than it would with a comparator that returned a boolean value to a general purpose register.

Conditional Move This scheme adds a conditional move instruction to the straight condition code model. In iloc, we write conditional move as

i2i < cci,rj ,rk rl

If the condition code cci matches <, then the value of rj is copied to rl. Otherwise, the value of rk is copied to rl.

Conditional move retains the potential advantage of the condition code scheme—avoiding the actual comparison operation—while providing a single instruction mechanism for obtaining a boolean from the condition code. The compiler can emit the instruction

i2i < cci,rt,rf rl