Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!noose.ecn.purdue.edu!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Inlining subroutines at link time
Message-ID: <2305@l.cc.purdue.edu>
Date: 4 Jul 90 01:48:00 GMT
References: <1990Jul3.194348.21178@msuinfo.cl.msu.edu> <9595@brazos.Rice.edu>
Organization: Purdue University Statistics Department
Lines: 32

In article <9595@brazos.Rice.edu>, preston@titan.rice.edu (Preston Briggs) writes:
> In article <1990Jul3.194348.21178@msuinfo.cl.msu.edu> riordanmr@clvax1.cl.msu.edu (Mark Riordan) writes:

			............................

> There's a rumour that some Unix C compilers do similar things.
> Generally though, it seems a waste, particularly for Fortran.
> Consider the time spent in a subroutine versus a savings of two
> instructions -- hardly worth the time to specify an extra compile flag.

I have difficulty seeing how a linker can inline, as register conflicts
must be avoided.  If it can change the register allocations, it may,
however, do very well.

As for saving only two instructions, these instructions are likely to
be very time-consuming, usually at least partially blocking internal
parallelism.  I far too many machines on which a transfer should be
considered a catastrophic instruction.

> Inlining before optimization has the potential for being a lot
> more interesting.  The hard part is choosing (automatically)
> routines to inline.  It's fairly easy to eliminate most of the
> calls in a program, but is the code any faster?  Often not.

I agree completely.  But in the next millenium, any intelligent
programmer will do better without working hard at these decisions
than an automaton.   Why are people in the computer field so 
determined to get in the way of using brainpower?
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)