Re: the Evil Effects of Inlining

      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:


What is naive inlining? Inlining without measuring the gain? Doing any
program transform on the thought that it might help is known to be a bad
strategy. Why pick on inlining?


On a more general note, I would guess that part of the reason you are down
on inlining is because your local coding style has the programmer
automatically providing the inlining, instead of writing in a more
procedural and abstract form. Therefore you see plus or minus 20%
performance changes. In both CLU style and Lisp style programming,
inlining of small functions yields large performance gains.


Your other arguments are not so clear cut.


      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.


For small procedures, code growth is minimal. Inlining decreases data
shuffling and other overhead. As I-Caches get bigger the slightly
increased code size becomes less and less important.


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


This merely means we have to make better register allocators.


      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.


But you have to recompile a program of any size when a structure
declaration changes. Why persecute functions and not structures? You
have to draw the line somewhere, but you should be aware that you are
drawing a line in a place that someone else may not agree with.


      INLINING ISN'T AS GOOD AS INTERPROCEDURAL ANALYSIS: ...


Inlining + interprocedural analysis > just interprocedural analysis.
Also, if one isn't doing interprocedural analysis, inlining is the next
best thing.


      Inlining is ineffective


As I state above, this really is a function of how programs are written.
For your local writing style and compiler this may be true.


      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.


Your argument boils down to: inlining doesn't help our code, and makes our
tools less useful. For other people's code and tools, inlining is can be
vital. For example, CLU code would run much slower if the compiler didn't
inline small functions. I know production C++ programmers who turn on
inlining in the last stages of developement (I am thinking in particular
of developers at a computer company working on a large experimental OS).
I don't remember the speedups they get, but it's substantial enough to
warrant using inlining even though it hurts debugging.


I suspect that the reason is that there is disagreement on this issue is
that neither of us are quantifying what is being inlined. I would buy
your arguments for larger procedures, and you would probably buy mine for
smaller procedures.


Daniel Weise
--

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