Lecture Notes in Computer Science 4917

394 Y. Ben Asher et al.
1. Ideally, the best reordering trace starts with the hot basic block BB1 in foo,
followed by the hot basic blocks BB5 and BB7 in bar itself, and finally the
hot basic blocks BB2 and BB4 that follow the call instruction to bar in foo.
This trace reordering is given in Figure 7b. Unfortunately, although this is
the ideal reordering trace, there is an extra jump instruction to BB2 that we
are forced to add immediately after the call instruction to bar. Theextra
jump instruction is necessary to maintain the original program correctness,
so that the return instruction in bar will continue to BB2.
2. In order to avoid the extra jump instruction, it is possible to form two
reordering traces. A trace consisting of the hot basic blocks in foo: BB1,BB2,
and BB4, is followed by a second trace consisting of the hot basic blocks in
bar: BB5 and BB7. The resulting code for this selection of reordering traces
is shown in Figure 7c. Although this selection does not generate extra jumps
for maintaining correctness, it does not reflect the true control flow of the
program, as it avoids creating traces that can cross function boundaries.
Figure 7 shows that after inlining bar at the call site in foo, the code reordering
creates the optimal hot path without the extra jump or return instructions,
and by following the true control flow. Furthermore, function inlining increases
the average size of each reordering trace. In Figure 7, the reordering trace size
after function inlining includes six instructions, which is longer than each of the
reordering traces BB1,BB2,BB3 or BB5,BB7, shown in Figure 7c.
The longer the traces produced by code reordering, the better the program
locality. We assert that the average size of traces created before aggressive inlining
vs. the average size after inlining can serve as a measure for the improvement
to the reverse effect where inline helps code reordering. In general, the average
size of traces increases due to function inlining: traces that started to grow in a
certain function can now grow into the corresponding inlined callee functions.
4.1 Synergy Experimental Results
The following experimental results demonstrate this “reverse effect” and synergy
between function inlining and code reordering on the Power4. The Power4 has
an extensive set of Performance Counters (PMCs), that enable us to isolate
the reasons for a program’s behavior. These count the L1 Icache fetches and
branch target mispredictions. Figure 8 shows the improvements of reduced L1
Icache fetches (percentage) comparing code reordering and the combination of
inlining and code reordering (denoted as “aggressive inlining”). The average
improvement due to inlining is from 16% to 24%. More significant results are
presented in Figure 9, which shows the percentage of reduced branch target
mispredictions. The code ordering scheme adds extra branches, which cause extra
target mispredictions. Applying the aggressive inlining scheme removes many
of these branches and reduces the number of target mispredictions for most
applications. The direction mispredictions are reduced as well, albeit at a lower
rate (3%) than the target mispredictions.
We have also tested the synergy between code reordering and inlining on the
PowerPC 405 processor used for embedded systems. The PowerPC 405 is the core