Short code to determine compiler's number of registers

[Tim Olson]

In article <547 at ksr.UUCP> johnm at ksr.UUCP (John Martin) writes:
| In article <18603 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
| >
| >... the way to find out how many registers the compiler will
| >use on your code is to compile your code and count how many registers
| >were used.  This is completely reliable, although not necessarily
| >repeatable.  It is also likely to be a useless statistic.
| >-- 
| >In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
| >Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris
| 
| All true.  For amusement's sake though, here is a C program that finds
| out what register variables one can have by looking at their effect on
| execution time, which presumably is why one might want to know in the
| first place.  The following example works with gcc and cc on Sun
| 3's and 4's running SunOS 3.5, and should work on most UNIX machines
| with little change.   As is frequently noted, timing routines are not
| very portable across OS's; sorry about that.

This method still doesn't work reliably, for a couple of reasons. 
First, the lifetimes of the declared register variables don't overlap,
so a compiler with register coloring could see that they all could be
replaced with a single shared register.  Second, even if a variable was
forced to memory, the LOOP macro test sequence:

     while (timing) { var--; var++; var--; var++; var++; } \

will not necessarily load and store the value to memory at each
increment/decrement.  Rather, the compiler is free to load the value
into a register before entry to the while-loop, computing all values in
that register, and storing the final result back to the variable's
memory address at loop exit.

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