Re: why not inline all functions?

Mark Sanvitale <sanvitam@std.teradyne.com> writes:


> ... why not make
> a compiler which turns every function into an inline function? This
> would save you the overhead inherent in a traditional function call
> (push everything defining the current state of the processor on the
> stack, make fresh copies of the parameters for the function, and,
> afterwards, pop things off the stack to return the processor to the
> pre-function state, not to mention losing the chance to take advantage
> of any instruction prefetching the processor might do).
> ...
> Perhaps compilers already take advantage of the idea I have outlined or
> perhaps there are some problems with the idea which I don't know about
> (an old C++ book I have says, "Compiler limits prevent complicated
> functions from being inlined," but no further explanation is given.
>
> What do you all think?


While working on high-level optimization at HP, some colleagues and I
essentially pursued a similar idea. Our goal was not so much to remove
call overhead as it was to open up larger expanses of code to
aggressive intraprocedural optimization. Some of the results are
summarized in a paper "Aggressive Inlining" which we presented at PLDI
last year. HP-UX compilers from 9.x onwards are capable of aggressive,
profile-driven, cross-module inlining.


Interprocedural optimization was (and is) often hampered by the
complexity and scale of the supporting interprocedural analyses and
whole-program information is often required to get good results. Once
you've done the analysis you often end up duplicating callee code to
take advantage of some specialized calling context. Inlining does this
duplication and specialization for you without requiring much
heavyweight analysis.


We saw very good results on most codes -- benchmarks, certainly, but
also many user and production codes and some parts of the HPUX
kernel. Fortran was actually trickier than C or C++ because the formal
parameter aliasing properties are difficult to describe accurately
once a subroutine is inlined. The only program I remember us actually
"flattening" completely was the spec benchmark fpppp.


On the flip side, getting good results with inlining requires
profiling, but this is quickly becoming a must for any aggressive
optimizing compiler. The code placement tool (ala Pettis & Hanson)
needs to be inlining-aware. Code growth is not that big of a problem
in many codes. Many very large codes have relatively small dynamic hot
spots. Database codes are a notable exception. Another big downside
is that aggressive cross-module inlining builds in cross-module
dependences, so you lose the quick build-time benefits of separate
compilation. Debugging runtime failures in heavily inlined code is a
huge challenge. And finally, many user codes are not interprocedurally
clean, making it hard to inline at some sites and preserve whatever
twisted semantics were implied by the original call.


-- Andy Ayers
--

Return to the comp.compilers page.
Search the comp.compilers archives again.