Cooper K.Engineering a compiler

Digression: Short-circuit evaluation as an optimization

Short-circuit evaluation arose naturally from a positional encoding of the value of boolean and relational expressions. On processors that used condition codes to record the result of a comparison and used conditional branches to interpret the condition code, short-circuiting made sense.

As processors include features like conditional move, boolean-valued comparisons, and predicated execution, the advantages of short-circuit evaluation will likely fade. With branch latencies growing, the cost of the conditional branches required for short-circuiting will grow. When the branch costs exceed the savings from avoiding evaluation, short circuiting will no longer be an improvement. Instead, full evaluation would be faster.

When the language requires short-circuit evaluation, as does c, the compiler may need to perform some analysis to determine when it is safe to substitute full evaluation for short-circuiting. Thus, future c compilers may include analysis and transformation to replace short-circuiting with full evaluation, just as compilers in the past have performed analysis and transformation to replace full evaluation with short circuiting.

where rt is known to contain true and rf is known to contain false. The e ect of this instruction is to set r1 to true if condition code register cci has the value <, and to false otherwise.

The conditional move instruction executes in a single cycle. At compile time, it does not break a basic block; this can improve the quality of code produced by local optimization. At execution time, it does not disrupt the hardware mechanisms that prefetch and decode instructions; this avoids potential stalls due to mispredicted branches.

Boolean-valued Comparisons This scheme avoids the condition code entirely. The comparison operation returns a boolean value into either a general purpose register or into a dedicated, single-bit register. The conditional branch takes that result as an argument that determines its behavior.

The strength of this model lies in the uniform representation of boolean and relational values. The compiler never emits an instruction to convert the result of a comparison into a boolean value. It never executes a branch as part of evaluating a relational expression, with all the advantages ascribed earlier to the same aspect of conditional move.

The weakness of this model is that it requires explicit comparisons. Where the condition-code models can often avoid the comparison by arranging to have the condition code set by one of the arithmetic operations, this model requires the comparison instruction. This might make the code longer than under the condition branch model. However, the compiler does not need to have true and false in registers. (Getting them in registers might require one or two loadIs.)

Predicated Execution The architecture may combine boolean-valued comparisons with a mechanism for making some, or all, operations conditional. This

The following loop nest shows the e ect of row-major order on memory access patterns.

for i ← 1 to 2 for j ← 1 to 4

A[i,j] ← A[i,j] + 1

In row-major order, the assignment statement steps through memory in sequential order, beginning with A[1,1] and ending with A[2,4]. This kind of sequential access works well with most memory hierarchies. Moving the i loop inside the j loop produces an access sequence that jumps between rows, accessing A[1,1], A[2,1], A[1,2], . . . , A[2,4]. With a small array like A, this is not a problem. With larger arrays, the lack of sequential access could produce poor performance in the memory hierarchy. As a general rule, row-major order produces sequential access when the outermost subscript varies fastest.

The obvious alternative to row-major order is column-major order. It keeps the columns of A in contiguous locations, producing the following layout.

Column major order produces sequential access when the innermost subscript varies fastest. In our doubly-nested loop, moving the i loop to the innermost position produces sequential access, while having the j loop inside the i loop produces non-sequential access.

A third alternative, not quite as obvious, has been used in several languages. This scheme uses indirection vectors to reduce all multi-dimensional arrays to a set of vectors. For our array A, this would produce

A: 1,1 1,2 1,3 1,4

XzX 2,1 2,2 2,3 2,4

Each row has its own contiguous storage. Within a row, elements are addressed as in a vector (see Section 8.5.1). To allow systematic addressing of the row vectors, the compiler allocates a vector of pointers and initializes it appropriately.

This scheme appears simple, but it introduces two kinds of complexity. First, it requires more storage than the simpler row-major or column-major layouts. Each array element has a storage location; additionally, the inner dimensions require indirection vectors. The number of vectors can grow quadratically in the array’s dimension. Figure 8.6 shows the layout for a more complex array, B[1..2,1..3,1..4]. Second, a fair amount of initialization code is required to set up all the pointers for the array’s inner dimensions.

Each of these schemes has been used in a popular programming language. For languages that store arrays in contiguous storage, row-major order has been the typical choice; the one notable exception is Fortran, which used columnmajor order. Both bcpl and c use indirection vectors; c sidesteps the initialization issue by requiring the programmer to explicitly fill in all of the pointers.

Figure 8.6: Indirection vectors for B[1..2,1..3,1..4]

8.5.3Referencing an Array Element

Computing an address for a multi-dimensional array requires more work. It also requires a commitment to one of the three storage schemes described in Section 8.5.2.

Row-major Order In row-major order, the address calculation must find the start of the row and then generate an o set within the row as if it were a vector. Recall our example of A[1..2,1..4]. To access element A[i,j], the compiler must emit code that computes the address of row i, and follow that with the o set for element j, which we know from Section 8.5.1 will be (j − low2) × w. Each row contains 4 elements, computed as high2 − low2 + 1, where high2 is the the highest numbered column and low2 is the lowest numbered column— the upper and lower bounds for the second dimension of A. To simplify the exposition, let len2 = high2 − low2 + 1. Since rows are laid out consecutively, row i begins at (i − low1) × len2 × w from the start of A. This suggests the address computation:

@A + (i − low1) × len2 × w + (j − low2) × w

Substituting actual values in for i, j, low1, high2, low2, and w, we find that A[2,3] lies at o set

((2 − 1) × 4 + (3 − 1)) × 4 = 24

from A[0,0]. (A actually points to the first element, at o set 0.) Looking at A in memory, we find that A[0,0] + 24 is, in fact, A[2,3].

In the vector case, we were able to simplify the calculation when upper and lower bounds were known at compile time. Applying the same algebra to adjust the base address in the two-dimensional case produces

@A + (i × len2 × w) − (low1 × len2 × w) + (j × w) − (low2 × w), or

@A + (i × len2 × w) + (j × w) − (low1 × len2 × w + low2 × w)

The last term, (low1 × len2 × w + low2 × w), is independent of i and j, so it can be factored directly into the base address to create

@A0 = @A − (low1 × len2 × w + low2 × w)

This is the two-dimensional analog of the transformation that created a false zero for vectors in Section 8.5.1. Then, the array reference is simply

@A0 + i × len2 × w + j × w

Finally, we can re-factor to move the w outside, saving extraneous multiplies.

@A0 + (i × len2 + j) × w

This form of the polynomial leads to the following code sequence:

In this form, we have reduced the computation to a pair of additions, one multiply, and one shift. Of course, some of i, j, and @A0 may be in registers.

If we do not know the array bounds at compile-time, we must either compute the adjusted base address at run-time, or use the more complex polynomial that includes the subtractions that adjust for lower bounds.

@A + ((i − low1) × len2 + j − low2) × w

In this form, the code to evaluate the addressing polynomial will require two additional subtractions.

To handle higher dimensional arrays, the compiler must generalize the address polynomial. In three dimensions, it becomes

base address + w ×

(((index1 − low1) × len2 + index2 − low2) × len3) + index3 − low3)

Further generalization is straight forward.

Column-major Order Accessing an array stored in column-major order is similar to the case for row-major order. The di erence in calculation arises from the di erence in storage order. Where row-major order places entire rows in contiguous memory, column-major order places entire columns in contiguous memory. Thus, the address computation considers the individual dimensions in the opposite order. To access our example array, A[1..2,1..4], when it is stored in column major order, the compiler must emit code that finds the starting address for column j and compute the vector-style o set within that column for element i. The start of column j occurs at o set (j − low2) × len1 × w from the start of A. Within the column, element i occurs at (i − low1) × w. This leads to an address computation of

@A + ((j − low2) × len1 + i − low1) × w

Substituting actual values for i, j, low1, low2, len1, and w, A[2,3] becomes

@A + ((3 − 1) × 2 + (2 − 1)) × 4 = 20,

so that A[2,3] is 20 bytes past the start of A. Looking at the memory layout from Section 8.5.2, we see that A + 20 is, indeed, A[2,3].

The same manipulations of the addressing polynomial that applied for rowmajor order work with column-major order. We can also adjust the base address to compensate for non-zero lower bounds. This leads to a computation of

@A0 + (j × len1 + i) × w

for the reference A[i,j] when bounds are known at compile time and

@A0 + ((j − low2) × len1 + i − low1) × w

when the bounds are not known.

For a three-dimensional array, this generalizes to

base address + w ×

(((index3 − low3) × len2 + index2 − low2) × len1) + index1 − low1)

The address polynomials for higher dimensions generalize along the same lines as for row-major order.

Indirection Vectors Using indirection vectors simplifies the code generated to access an individual element. Since the outermost dimension is stored as a set of vectors, the final step looks like the vector access described in Section 8.5.1. For B[i,j,k], the final step computes an o set from k, the outermost dimension’s lower bound, and the length of an element for B. The preliminary steps derive the starting address for this vector by following the appropriate pointers through the indirection vector structure.

Thus, to access element B[i,j,k] in the array B shown in Figure 8.6, the compiler would use B, i, and the length of a pointer (4), to find the vector for the subarray B[i,*,*]. Next, it would use that result, along with j and the length of a pointer to find the vector for the subarray B[i,j,*]. Finally, it uses the vector address computation for index k, and element length w to find B[i,j,k] in this vector.

If the current values for i, j, and k exist in registers ri, rj , and rk, respectively, and that @B0 is the zero-adjusted address of the first dimension, then

This code assumes that the pointers in the indirection structure have already been adjusted to account for non-zero lower bounds. If the pointers have not