Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!gem.mps.ohio-state.edu!think!ames!pacbell!att!dptg!ulysses!andante!alice!bs
From: bs@alice.UUCP (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: inline policy
Message-ID: <10121@alice.UUCP>
Date: 11 Nov 89 23:25:39 GMT
References: <21599.255be7e0@ceres.physics.uiowa.edu>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 44



On inlining:

Inlining is an optimization. In most cases inlining is best used only
after profiling has given you a good idea where the function call
overhead is significant enough to be worth optimizing away.

Personally, I typically use inlining only for ``one liners'' where
a function body is ``clearly'' shorter than the function call it
would replace.

The value of inlining depends critically on the target machine architecture.
Typically, inlining is worthwhile more frequently for a machine with
a relatively slow function call.

Some inlining can be done by some linkers. The C++ mechanism for inlining
attempts to make necessary optimizations independent of the smarts of the
linker used. Most linkers are not smart enough to do significant inlining.
Thus, the C++ inlining mechanism can be seen as a portability aid.

Not every call of an inline function can be inlined. Consider a pair of
mutually recursive inline functions with a non-trivial criteria for ending
the recursion. In the limit, this is the halting problem. The criteria for
when to inline will be compiler dependent. Cfront will inline a function
at most once in a single expression. The primary reason for this is to
protect against recursion. A secondary reason is to allow different inlinings
of a function in a block to share local temporary variables. The latter can
be important on architectures with limited stack space.

If the address of an inline function is taken or if it is decided that a call
of an inline cannot be inlined an ``outline'' version must be layed down
somewhere. Since `inline' implies internal linkage the obvious thing to
do is to lay down a `static' function. Doing this in several files can
cause several ``outlined'' copies of a single inline function to be layed
down. Such replication can be avoided, but currently no cfront/linker
combination does that.

It is possible for a compiler to estimate the relative cost of a function
call and inlining of the called function. Cfront makes such estimates
and outlines a function if the inlined code would be ``too large''
relative to the call. This is a source of outlined inlines. Improvements
are clearly possible here.