Xref: utzoo comp.lang.c:27131 comp.lang.misc:4595
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: function calls
Message-ID: <14285@lambda.UUCP>
Date: 22 Mar 90 21:23:26 GMT
References: <29585@amdcad.AMD.COM>
Lines: 42

From article <29585@amdcad.AMD.COM>, by tim@nucleus.amd.com (Tim Olson):
> [...]
> The compiler that I used to collect the stats will keep all live
> scalars in the register file, [...]                    [^^^]

I don't believe a word of it.  The word I don't believe is 'all'.
_ANY_ scalar that is visible in the local scope and has a value
which might still be used by the program at some future point is 'live'.
(The same obviously applies to non-scalar values.)  That is the definition
of 'live'.  What you really mean is that the compiler breaks code into
'basic blocks' and keeps all active values from _that_ block in registers.
The use of 'basic blocks' and the lack of global dataflow analysis is
confusing you into thinking that only a few values are 'live' at a given
point.  Also, it is considerable mistake not to regard non-scalar values
as important.

The bottom line is that registers are an important resource in any machine.
They are often more that 10 times faster than memory to reference.  Your
analysis indicates that your code (whether the compiler is responsible
or not) is using this resource to only a small fraction of its potential.
But instead of complaining, you are acting like it is a desireable way
for the code to behave.

> | My experience (I don't have statistics) with both Fortran and C is that
> 		 ^^^^^^^^^^^^^^^^^^^^^^^
> Oh.

Ok, now I have statistics.  I just did a quick survey of some expertly
crafted C code that I have source code to (it's actually part of the
X11 window package).  This is only a small program (it's xlock for those
interested in checking).  Still, there are over 50 scalar variables
declared global to the utility - these are _ALWAYS_ 'live'.  Further,
this code includes a lot of window related declarations (which also
contain a bunch of _ALWAYS_ 'live' global declarations).  This is
admittedly a small sample and it disregards local variables and non-scalars.
Still, since most of the program consists of small procedures which
manipulate these global variables, I suspect it would be a smaller, faster
code if the values always occupied registers.  xlock probably doesn't
need to be faster, but if speed were important, register usage would
be too.

J. Giles