Re: the Evil Effects of Inlining

In article <1991May2.180508.17100@rice.edu> preston@ariel.rice.edu (Preston Briggs) writes:
      carter@cs.wisc.edu (Gregory Carter) writes:
      [wondering about inlining the world]
      Don't forget to be careful of recursion!


Homework assignment: figure out how to inline with recursion (Yes, I
did it. Turned out to be pretty neat :^).


      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:


I have found several places where inlining is very useful, but they all
seem to be in the Lisp world. In the compiler (for CL/Scheme) I worked on
we used inlining quite heavily to optimize the language runtimes. However,
we were careful about it - we would only inline a procedure if it didn't
cause code explosion or if there was some reason the extra code would get
folded away. For example, if we saw an "aref" call (CL's general purpose
array reference) and we could determine that the argument was a simple
vector, we would fold it away producing a simple vector ref. We didn't
just blindly inline the whole mess (which was 50-100 lines of code) and
hope that it would go away.


John
gateley@rice.edu
--

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