why not inline all functions?

Mark Sanvitale <sanvitam@std.teradyne.com>
9 Jun 1998 12:03:34 -0400

          From comp.compilers

Related articles
why not inline all functions? sanvitam@std.teradyne.com (Mark Sanvitale) (1998-06-09)
Re: why not inline all functions? cliff.click@Eng.Sun.COM (Clifford Click) (1998-06-11)
Re: why not inline all functions? p.toland@computer.org (Phillip Toland) (1998-06-11)
Re: why not inline all functions? f81@ix.urz.uni-heidelberg.de (Joerg Schoen) (1998-06-11)
Re: why not inline all functions? bje@cygnus.com (Ben Elliston) (1998-06-11)
Re: why not inline all functions? ayers@incert.com (Andy Ayers) (1998-06-11)
Re: why not inline all functions? mcdirmid@beaver.cs.washington.edu (1998-06-11)
[10 later articles]
| List of all articles for this month |

From: Mark Sanvitale <sanvitam@std.teradyne.com>
Newsgroups: comp.compilers
Date: 9 Jun 1998 12:03:34 -0400
Organization: Teradyne, Incorporated
Keywords: performance

Functions are great for making written code (C, C++, etc.) mode
readable and structured, however, they do not seem to make much sense
when you get down to the raw machine code which actually is executed
by a processor.


As far as my understanding of the matter goes, the most basic way to
slow down a processor is to make it execute an instruction besides the
one immediately following the current instruction, thus, 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).


The output of such a compiler would be larger binary files (since
every call to a function would expand to the entire function body)
however the execution time for such a program should be improved
(relative to a non-inlining compiler) by a factor proportional to the
number of function calls in the program.


Now, a "inline everything" scheme might run into some roadblocks when
it comes to external functions which are resolved at link time and the
notion of dynamic linking is not compatible with such a method.
Still, I think compilers should try to inline every function it can
without depending on the programmer to specify a function as "inline"
(C++).


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?


NOTE - During my quest for a CS degree I did not have the chance to take
a compilers course (it was a tech elective which never fit in my
schedule) so if my assertion is totally pointless please just point out
the reason I am wrong and spare me the "Are you stupid/crazy/lost"
comments. In the area of compilers I admit to being fairly ignorant (as
far as professional programmers go).


Mark S
"computer geek and movie freak"
[Well, if you ignore recursive and mutually recursive functions which
can't be in-lined, the main problem is code bloat. Remember that since
computers have fairly small caches and finite main memory, big code can
run slower due to cache reloads and page faults, even though you aviod
relatively slow procedure calls and returns. Aggressive optimizing
compilers (usually for Fortran) do indeed do a lot of in-lining already,
though. -John]


--


Post a followup to this message

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