the Evil Effects of Inlining

carter@cs.wisc.edu (Gregory Carter) writes:


[wondering about inlining the world]


Don't forget to be careful of recursion!


and the moderator notes


>[GCC and some other C compilers permit you do declare a procedure "inline"
>so that it is expanded wherever it is called. That gives pretty much the
>same effect, faster but larger code. -John]


Locally, we're pretty down on naive inlining. I think there are some
cases where it pays, but they are much rarer than imagined. So, here's a
list of reasons not to inline:


Code growth


Replicating procedure bodies in many places.
Can have bad effects on paging, TLB, I-Cache.
(however, may improve locality sometimes.)


Hurts compile-time, since optimizers are pretty
sensitive to code size.




Register pressure


Call sites are natural places to spill lots of registers.
Register allocators are rarely able to achieve the same efficiency.




Massive recompilation


When you edit an inlined routine, you've got to recompile
everyone that calls the routine. On big programs (say an OS
or perhaps a reservor simulator), this is a Bad Thing.


People sometimes argue that the inlining is only done at the last
second, after code has been debugged. I don't think this is
a good argument. Code is always being debugged, especially the
big things, like OS's. Further, big programs take a lot of
performance tuning, usually done with full optimization.


Surely everyone knows not to do initial development
with the optimizer turned on?




Inlining isn't as good as interprocedural analysis


Interprocedural analysis can track across the entire program,
including loops in the call graph (recursion). Inlining
only gets effects on procedures actually inlined.


Imagine a huge program, with many constant parameters set by the
main routine. Interprocedural constant propagation will get
these constant all through the code; inlining won't get anything
unless it's inlined into the main routine.




Inlining is ineffective


We've tried lots of experiments, with a variety of code
on a variety of machines (scalar, vector, parallel, RISC, and CISC).
Sometimes we manage a 20% improvement.
Sometimes we degrade by up to 20%. Usually, there's only
a fractional change one way or another.
It's very difficult to predict when it will pay off.




We believe that many people know these things, often from
experimentation. However, nobody likes to publish negative results.
Hence, the knowledge has been Supressed.


------------------


Obviously, inlining is not completely Evil.
However, I think it has been over-sold and over-used.
This is a little attempt to even the balance.


Preston Briggs
--

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