Re: the Evil Effects of Inlining

daniel@quilty.Stanford.EDU (Daniel Weise)
3 May 91 09:37:20

          From comp.compilers

Related articles
the Evil Effects of Inlining (1991-05-02)
Re: the Evil Effects of Inlining (1991-05-03)
Re: the Evil Effects of Inlining daniel@quilty.Stanford.EDU (1991-05-03)
Re: the Evil Effects of Inlining (1991-05-03)
Re: the Evil Effects of Inlining (1991-05-03)
Re: the Evil Effects of Inlining (1991-05-03)
Re: the Evil Effects of Inlining (1991-05-03)
Re: the Evil Effects of Inlining compres! (1991-05-04)
Re: the Evil Effects of Inlining (1991-05-05)
[3 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: daniel@quilty.Stanford.EDU (Daniel Weise)
In-Reply-To:'s message of 2 May 91 18:05:20 GMT
Keywords: optimize, design
Organization: Computer Systems Laboratory, Stanford University
References: <> <> <> <>
Date: 3 May 91 09:37:20

      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.

      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.

      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.


      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 + 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

Post a followup to this message

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