Xref: utzoo comp.lang.c:27248 comp.lang.misc:4659
Path: utzoo!attcan!uunet!cs.utexas.edu!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: function calls
Message-ID: <14293@lambda.UUCP>
Date: 26 Mar 90 22:54:14 GMT
References: <PCG.90Mar25230051@rupert.cs.aber.ac.uk>
Lines: 19

From article <PCG.90Mar25230051@rupert.cs.aber.ac.uk>, by pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi):
> [...]                                           The problem that Giles
> does not seem to consider is that caching values in registers is only
> useful if the values are going to be used repeatedly, like all forms of
> caching. 

I don't see where I've been at fault here.  The _definition_ of 'live'
values it that they are to be used again.  The more of these that you
can place into registers the better.  The compiler should do sufficient
data flow so that it knows which 'live' values are needed next and should
schedule registers to preload these (and hold them until other values are
of more immediate use).  Procedure calls interrupt this analysis (at least,
if you don't have interprocedural analysis).  This problem doesn't go away
(even with your well known masochistic micro-management style of programming)
without hand 'inlining' or automatic interprocedural analysis.  In fact,
hand 'inlining' is just the sort of micro-optimization that your style of
programming would recommend!  So, in this case, we should be in agreement.

J. Giles