Path: utzoo!utgpu!watserv1!watmath!att!rutgers!usc!samsung!noose.ecn.purdue.edu!cadlab1.ecn.purdue.edu!3ksnn64
From: 3ksnn64@cadlab1.ecn.purdue.edu (Joe Cychosz)
Newsgroups: comp.arch
Subject: Re: Inlining subroutines at link time
Message-ID: <1990Jul6.012548.27574@ecn.purdue.edu>
Date: 6 Jul 90 01:25:48 GMT
References: <1990Jul3.194348.21178@msuinfo.cl.msu.edu> <9595@brazos.Rice.edu> <2305@l.cc.purdue.edu>
Sender: news@ecn.purdue.edu (USENET news)
Organization: Purdue University Engineering Computer Network
Lines: 39

In article <2305@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>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.

I believe it does make register reassignments during inlining.  My memory
is a bit fuzzy on this since the afterburner became a formal product after
I stopped working on the 995 and began work on the ETA10s.

>> 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.

Yes, especially on vector processors and scalar machines with a fast
loop control instructions.  On most machines it would not be worth the
effort, however on the 995 it is essential.

>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?

May be so we can use that brainpower for something else.  It is fairly
difficult to beat todays optimizers.  You may find a better way, but more
than likely you'll realize less than 2% savings.  Of course there are
always the exceptions, after all a optimizer is a program and is thus
subject to errors, and re-organizing the algorithm or process is outside
of the scope of an optimizers function.