Lecture Notes in Computer Science 4917

Aggressive Function Inlining: Preventing Loop Blockings 389
5. Sort CG in topological order.
6. Traverse the sorted graph from the root in descending order. For each function
f:
(a) Duplicate the code of function f for each of the call sites that have an
outgoing edge to f. All relevant information related to the copies of f
(f1,f2,...), such as symbolic information, branch tables, traceback data,
etc., are duplicated as well.
(b) Update the selected call sites to f, tocallitscopies.
(c) Update the weights of the edges in both the call graph and the control
flow graphs of both f and its copies, to reflect the changes resulting from
duplicating f. For example if a function f is called 100 times from g and
200 times from h then the weights of the edges in each copy of f should
be divided by this ratio as well.
7. Traverse all the functions in CG starting from the leaf functions in ascending
order. For each function fi:
Embed fi into its calling function g while eliminating the save, restore, call,
and return instructions.
8. Update CG and EG to reflect the changes resulting from inlining f.
2.1 ILB Experimental Results
We implemented the various inlining algorithms into IBM FDPR-Pro - a postlink
optimization tool. Measurements were obtained on the SPEC CINT2000
benchmark running on platforms based on the following processors:
1. IBM Power4 that has a 64KB, direct mapped, L1 Instruction Cache with
128-byte lines.
2. AMCC 440GX that has a 32KB, 64-way associative, L1 Instruction Cache
with 32-byte lines.
In both measurements, FDPR-Pro was also used to collect the profiling data by
instrumenting the benchmarks and running them on the train workload. Performance
measurements were collected using the reference input. The following
graphs compare ILB versus four inlining methods:
all - all executed functions that were somewhat hot.
hot - all functions that are above the average heat.
dominant - call sites that make more than 80% of the executed calls to the
function.
small - only small size functions.
This was also repeated for the embedded CPU. The results in Figure 3 show
that ILB improves the execution time by 10% compared to the other four methods.
Note that the ILB almost never degraded the performance compared to
the “base” case, while there are cases where small, hot and all reduced the performance.
Note that dominant calls are a subset of ILB since a hot call that is
repeated in a hot cycle can not be dominant. This indicates that ILB is safer than