function calls

[Tim Olson]

In article <14281 at lambda.UUCP> jlg at lambda.UUCP (Jim Giles) writes:
| From article <29551 at amdcad.AMD.COM>, by tim at nucleus.amd.com (Tim Olson):
| > [...]
| > It might be true that scientific routines written in FORTRAN may have
| > this many live, non-overlapping variables to keep in registers, but I
| > don't believe this is true in general.  Statistics from a large
| > collection of programs and library routines (a mix of general and
| > scientific applications written in C) show that of 782 functions (620
| > of which were non-leaf functions), an average of 6.5 registers per
| > function were live across function calls.
| 
| This statistic can only be interpreted in one way: the C compiler in
| question didn't allocate registers very well.  Especially in scientific
| packages, there are _HUGE_ numbers of 'live' _VALUES_ to deal with during
| execution of even simple routines.  Vectors, arrays, lists, strings, etc,
| are alle being either produced or consumed.  The fact that none of these
| _VALUES_ were in registers at the time of the call indicates one of two
| things: 1) the code in question was fragmented to the point that most
| procedures had only a few data items (and scalar at that), or 2) the
| compiler simply wasn't using the registers to anywhere near their potential.
| Since you imply the code was well written, I reject the first explanation.
| That leaves the compiler.

Do you have any statistics to back up your assertions?  The values I
quoted match what other people have found as well.  Again, you may be
only looking at a small portion of scientific code and missing what is
going on in general code.

The compiler that I used to collect the stats will keep all live
scalars in the register file, but doesn't do inlining of functions,
and doesn't try to operate on arrays in registers (how do you generate
code to deal with runtime address calculations???)

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


	-- Tim Olson
	Advanced Micro Devices
	(tim at amd.com)