Lecture Notes in Computer Science 4917

Aggressive Function Inlining: Preventing Loop Blockings 385
responsible for most of the branch mis-predictions. Inlining eliminates many
return instructions thus “freeing” significant amount of entries in the branch
history tables. 1 Finally, eliminating the code of the function’s prologue and epilogue
may further reduce execution time.
In spite of these potentials, inlining is not used aggressively and is usually
applied to restricted cases. The reason is that aggressive function inlining can
cause code bloat and consequently instruction cache (Icache) conflicts; thus,
degrading performance. In particular, different copies of the same function may
compete for space in the Icache. If a function is frequently called from different
call sites, duplicating it can cause more cache misses due to frequent references
to these multiple copies or to code segments that are activated through them.
The main problem with inlining is that the final instructions’ locations (addresses
in the final executable) are determined only after inlining is completed.
Consequently, it is not possible to determine which inlinings will eventually lead
to Icache conflicts. Many optimizations that modify the code and change its location
are applied after inlining (such as scheduling and constant propagation).
An important optimization that dramatically alters code locations and is applied
after inlining is code reordering [7]. Code reordering groups sequences of
hot basic blocks (frequently executed) in ordered “chains” that are mapped to
consecutive addresses in the Icache. Thus, code reordering can reduce or repair
part of the damage caused by aggressive inlining decisions. However, it does not
eliminate the need to carefully select the inlined function calls.
Even sophisticated versions [2] of code reordering that use cache coloring
techniques can not repair the damage caused by excessive inlining. This inherent
circular dependency leads compiler architects to use heuristics for function
inlining. Current inlining methods use a combination of these basic methods and
they differ only in the criterion/threshold of when to use a given basic method:
– inline only very small functions, basically preserving the original code size.
– inline a function if it only has a single caller. Thus, preserving or even reducing
the original code size. This is extended to inlining only dominant calls,
i.e., call sites that account for the majority of calls for a given function.
– inline only hot calls, not necessary the dominant ones.
– inline if a consecutive chain of basic blocks does not exceed the size of the
L1 Icache.
– inline calls with constant parameters whose substitution followed by constant
propagation and dead code elimination will improve performance. This criterion
was proposed and used in [5] for the related optimization of function
cloning, i.e., create a specialized clone of a function for a specific call site2 .
We have experimented with these rules in IBM’s FDPR-Pro tool which is a post
link optimizer [7] and discovered that they are too restrictive and can prevent
many possible inlinings that could lead to significant code improvement.
1 This is important in processors with deep pipelines or minor branch prediction support.
The latter attribute is prevalent in leading high-end embedded processors.
2 Cloning is less efficient than inlining since it does not increase the size of consecutive
chains of hot basic blocks.