Lecture Notes in Computer Science 4917

Aggressive Function Inlining: Preventing Loop
Blockings in the Instruction Cache
Yosi Ben Asher, Omer Boehm, Daniel Citron,
Gadi Haber, Moshe Klausner, Roy Levin, and Yousef Shajrawi
IBM Research Lab in Haifa, Israel
Computer Science Department Haifa University, Haifa Israel
{omerb,citron,haber,klausner}@il.ibm.com
Abstract. Aggressive function inlining can lead to significant improvements
in execution time. This potential is reduced by extensive instruction
cache (Icache) misses caused by subsequent code expansion. It is
very difficult to predict which inlinings cause Icache conflicts, as the exact
location of code in the executable depends on completing the inlining
first. In this work we propose a new method for selective inlining called
“Icache Loop Blockings” (ILB). In ILB we only allow inlinings that do
not create multiple inlined copies of the same function in hot execution
cycles. This prevents any increase in the Icache footprint. This method
is significantly more aggressive than previous ones, experiments show it
is also better.
Results on a server level processor and on an embedded CPU, running
SPEC CINT2000, show an improvement of 10% in the execution time
of the ILB scheme in comparison to other inlining methods. This was
achieved without bloating the size of the hot code executed at any single
point of execution, which is crucial for the embedded processor domain.
We have also considered the synergy between code reordering and
inlining focusing on how inlining can help code reordering. This aspect
of inlining has not been studied in previous works.
1 Introduction
Function inlining [1] is a known optimization where the compiler or post link
tool replaces a call to a function by its body, directly substituting the values
passed as parameters. Function inlining can improve instruction scheduling as it
increases the size of basic blocks. Other optimizations such as global scheduling,
dead code elimination, constant propagation, and register allocation may also
benefit from function inlining. In order to optimize the code that was generated
by the inlining operation, inlining must be executed before most of the backend
optimizations.
There is a special relation between inlining and embedded systems. Embedded
CPUs have relatively small branch history tables compared to servers. Aggressive
inlining can improve the branch prediction in embedded systems, compensating
for their relatively small number of entries. The reason is that return instructions
are implemented with branch-via-register instructions which are typically
P. Stenström et al. (Eds.): HiPEAC 2008, LNCS 4917, pp. 384–397, 2008.
c○ Springer-Verlag Berlin Heidelberg 2008