Short code to determine compiler's number of registers

[John Martin]

In article <26423 at amdcad.AMD.COM> tim at amd.com (Tim Olson) writes:
>In article <547 at ksr.UUCP> johnm at ksr.UUCP (John Martin) writes:
>>
>> [ A program to time variable access to look for registers.]
>>
>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.

If a compiler does coloring with optimization off, initialize the
variables so their lifetimes will be coterminous.  A compiler that
doesn't always store memory variables to memory before their next read
with optimization off would break this test -- and any standard
debugger.

Are there really compilers that do not regard coloring or dynamic
transfer of a variable between register and memory as suppressable
optimizations?  I'd like a list, so I can mark them in my mental map
with the label "Here be monsters."  Unless they come with good
debuggers that can understand them, they'd sure be obnoxious to use
for program development -- the only reliable debugger would be
assembly-level.




John H. Martin					harvard!ksr!johnm
Kendall Square Research Corporation		johnm at ksr.com
170 Tracer Lane
Waltham, MA 02154
"A creative economy is the fuel of magnificence." -- Emerson
Disclaimer:  My only organizationally-endorsed position is prone.