Cooper K.Engineering a compiler

Figure 8.9: Predication versus Branching

then and else parts, as shown in Figure 8.4, the primary consideration for the compiler is matching the expression evaluation to the underlying hardware. As the then and else parts grow, the importance of e cient execution inside the then and else parts begins to outweigh the cost of executing the the controlling expression.

For example, on a machine that supports predicated execution, using predicates for large blocks in the then and else parts can waste execution cycles. Since the processor must issue each predicated instruction to one of its functional units, the cost of a non-executed instruction is roughly the same as that of an executed instruction. For an if–then–else construct with large blocks of code under both the then and else parts, the cost of unexecuted instructions may outweigh the overhead of using a conditional branch.

Figure 8.9 illustrates this tradeo . The figure assumes that both the then and else parts contain ten independent iloc operations, and that the target machine can issue two instructions per cycle.

The left side shows code that might be generated using predication; it assumes that the code evaluated the controlling expression into r1. The code issues two instructions per cycle. One of those executes in each cycle. The code avoids all branching. If each operation takes a single cycle, it takes ten cycles to execute the controlled statements, independent of which branch is taken.

The right side shows code that might be generated using branches; it assumes that control flows to L1 for the then part and to L2 for the else part. Because the instructions are independent, the code issues two instructions per cycle. Following the then path, it takes five cycles to execute the operations for the taken path, plus the cost of the terminating branch. The cost for the else part

Digression: Branch Prediction by Users

One story that has achieved the status of an urban legend concerns branch prediction. Fortran has an arithmetic if statement that takes one of three branches, based on whether the controlling expression evaluates to a negative number, to zero, or to a positive number. One early ibm compiler allowed the user to supply weights for each label that reflected the relatively probability of taking that branch. The compiler then used the weights to order the branches in a way that minimized total expected delay from branching.

After the compiler had been in the field for some time, the story goes, a maintainer discovered that the branch weights were being used in the reverse order—maximizing the expected delay. No one had complained. The story is usually told as a moral fable about the value of a programmers’ opinions about the behavior of code they have written. (Of course, no one reported the improvement, if any, from using the branch weights in the correct order.)

is identical.

The predicated version avoids the initial conditional branch, as well as the terminating branch. The branching version incurs the overhead of both branches, but may execute faster. Each path contains a conditional branch, five cycles of operations, and the terminal branch (which is easily predicted and should have minimal cost.) The di erence lies in the e ective issue rate—the branching version issues roughly half the instructions of the predicated version. As the code fragments in the then and else parts grow larger, this di erence becomes larger.

Choosing between branching and predication to implement an if–then–else requires some care. Several issues should be considered.

1.expected frequency of execution for each part: If one side of the conditional is expected to execute significantly more often, techniques that speed execution of that path may produce faster code. This bias may take the form of predicting a branch, of executing some instructions speculatively, or of reordering the logic.

2.uneven amounts of code: If one path through the construct is contains many more instructions than the other, this may weigh against predication (unless it is infrequently executed).

3.control-flow inside the construct: If either path through the construct contains non-trivial control flow, such as another if–then–else, a loop, a case statement, or procedure call, predication may not be the most e cient choice. In particular, nested if constructs create more complex predicate expressions and lower the percentage of issued instructions that are actually executed.

To make the best decision, the compiler must consider all these factors, as well as the surrounding context. These factors may be di cult to assess early in compilation; for example, optimization may change them in significant ways.

The alternative is to use an absolute branch at the bottom of the loop that targets the update and conditional branch at the top of the loop body. This avoids replicating the update and conditional branch. However, it creates a two-block loop for even the simplest loops, and it typically lengthens the path through the loop by at least one operation. However, if code size is a serious consideration, then consistent use of this more compact loop form might be worthwhile. The loop-ending branch is unconditional and, thus, trivially predicted. Many modern processors avoid latency on unconditional branches by prefetching their targets.

The code for a Fortran do loop has a similar form, except for one odd quirk. The Fortran standard specifies that the number of iterations that a do loop makes is completely determined before the loop begins execution. Modifications to the induction variable made inside the loop body have no e ect on the number of times the loop iterates.

According to the Fortran standard, this example loop should execute its body one hundred times, despite the modifications to i inside the loop. To ensure this behavior, the compiler may need to generate a hidden induction variable, r4, to control the iteration. This extra variable is sometimes called a shadow variable.

Unless the compiler can determine that the loop body does not modify the induction variable, the compiler must generate a shadow variable. If the loop contains a call to another procedure and passes the induction variable as a call- by-reference parameter, the compiler must assume that the called procedure modifies the induction variable, unless the compiler can prove otherwise.4

4This is one case where analyzing the entire program (for example, with interprocedural data-flow analysis) routinely wins. Programmers pass induction variables as parameters so that they can include the induction value in debugging output. Interprocedural analysis easily recognizes that this does not change the induction variable’s value, so the shadow variable is unnecessary.

While Loops A while loop follows the same basic form, without the introduced overhead of an induction variable. The compiler emits code to evaluate the condition before the loop, followed by a branch that bypasses the loop’s body. At the end of the loop, the condition is re-evaluated and a conditional branch takes control back to the top of the loop.

Again, replicating the evaluation and test at the end of the loop creates a single basic block for the body of a simple loop. The same benefits that accrue to a for loop from this structure occur with a while loop.

Until Loops For an until loop, the compiler generates code similar to the while loop. However, it omits the first evaluation and test. This ensures that control-flow always enters the loop; the test at the bottom of the loop body handles the until part of the test.

The until loop is particularly compact, because it has no pre-loop sequence.

Expressing Iteration as Tail Recursion In Lisp-like languages, iteration is often implemented (by programmers) using a stylized form of recursion. If the last action of a function is a call, that call is considered a tail call. If the tail call is a self-recursion, the call is considered a tail recursion. For example, to find the last element of a list in Scheme, the programmer might write the following simple function:

(define (last alon) (cond

((empty? alon) empty)

((empty? (rest alon)) (first alon)) (else (last (rest alon)))))

Its final act is a tail-recursive call; this particular form of call can be optimized into a branch back to the top of the procedure. This avoids the overhead of a fully general procedure call (see Section 8.9). The e ect is to replace a procedure call with a branch that binds some parameters. It avoids most of the operations of the procedure call and completely eliminates the space penalty for creating new activation records on each tail call. The results can rival a for loop in e ciency.

discover a matching case label, or the absence of a match. Finally, it branches to the corresponding label.

For the case statement shown above, the following search routine and branch table might be used.

The code fragments for each block are now independent. The code fragment for block i begins with a label, LBi, and ends with a branch to Lnext.

The binary search discovers the appropriate case label, if it exists, in log2(n) iterations, where n is the number of cases. If the label does not exist, it discovers that fact and branches to the block for the default case.

Directly Computing the Address If the case labels form a dense set, the compiler can do better than binary search. In the example, the case statement has labels for every integer from zero to nine. In this situation, the compiler can build a vector that contains the block labels, LBi, and find the appropriate label by performing a simple address calculation.

For the example, the label can be found by computing t1 as before, and using t1 as an index into the table. In this scenario, the code to implement the case statement might be:

t1 ← b × c + d

if (0 > t1 || t1 > 9) then branch to LB10 else

t2 ← memory(@Table + t1 × 4) branch to t2

assuming that the representation of a label is four bytes.

With a dense set of labels, this scheme generates e cient code. The cost is both small and constant. If a few holes exist in the label set, the compiler can fill those slots with the label for the default case. If no default case exists, the compiler can create a block that generates the appropriate run-time error message and use that in place of the default label.