Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mstan!amull
From: amull@Morgan.COM (Andrew P. Mullhaupt)
Newsgroups: comp.arch
Subject: Re: Inlining subroutines at link time
Message-ID: <1184@s8.Morgan.COM>
Date: 4 Jul 90 17:44:09 GMT
References: <1990Jul3.194348.21178@msuinfo.cl.msu.edu> <9804@pt.cs.cmu.edu>
Organization: Morgan Stanley & Co. NY, NY
Lines: 20

In article <9804@pt.cs.cmu.edu>, lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:
> The architectural tie-in is that inlining disturbs the statistical
> properties of programs, increasing the number of registers used,
> enlarging the code, and affecting its locality.

There is also the possibility that I-cache behavior is affected
by inlining: Inline code is somewhat more sequential. You can really
lose on this one if you experience page faults from the larger
code size, however. 

In C, inlining can (depending on where it happens) allow for
more optimization of pointer accesses than if function calls
intervene.

The best known (or depending on your point of view most infamous)
case of inlining is when the Dhrystone benchmark is compiled with
some memory movement routines inline. 

Later,
Andrew Mullhaupt