Path: utzoo!utgpu!cunews!cognos!jimp
From: jimp@cognos.UUCP (Jim Patterson)
Newsgroups: comp.arch
Subject: Re: Optimising C compiler question
Message-ID: <9526@cognos.UUCP>
Date: 11 Apr 91 13:26:17 GMT
References: <1991Apr8.193155.3911@vax5.cit.cornell.edu> <1991Apr11.003431.24918@alzabo.ocunix.on.ca>
Reply-To: jimp@cognos.UUCP (Jim Patterson)
Distribution: comp
Organization: Cognos Inc., Ottawa, Canada
Lines: 56

In article <1991Apr11.003431.24918@alzabo.ocunix.on.ca> andras@alzabo.ocunix.on.ca (Andras Kovacs) writes:
>... 'register'-ing a var
>could have two possible effects:
>  1, It is obeyed - but then better if you know what you are doing otherwise
>     you can indeed slow down the code, or
>  2, Disregarded - because the compiler trusts itself that indeed it knows the
>     best allocation scheme.
>
>  I assume that good compilers use the second approach - not out of disregard
>to the programmer but either the programmer asks for the right var to be
>register and then it is already; or the compiler KNOWS that the register var
>would cost execution speed and then what is the point of using it?

I don't think a compiler can ever know absolutely that a given variable
should be in a register whereas another should not, for "performance".
It can't do anything more than guess at the actual code dynamics, and
therefore would be allocating registers based on assumptions which
could be totally erronous. Here's an example which should illustrate
this. 

Assume that there is 1 register free to allocate to either i or j. The
outer for-loop is allocating an array of things. The inner loop is an
error recovery routine and normally not executed; however, if a
compiler assumes that there is a 50% chance of the first if-condition
is going to succeed, it's going to weight j a lot higher than i for 
register allocation. This can't possibly be right if during normal
execution malloc never fails.

for (i=0 ; i<10000; ++i) {
    e=malloc(sizeof(element));
    if (!e) {
       for (j=0; j<10000; ++j)
          if (j < i)   
              free(table[j]);
       getout(); /* Leave routine now */
    }
    table[i] = e;
}

We could make a rule that a variable in a conditional block is weighted
enough lighter than one outside that the register allocation would go
to i instead of j, but then we can turn just as easily reverse the
test and find that now we should put j in the register, not i. Neither
allocation wins in all situations, but the compiler doesn't have enough
information to know which is best.

Things are different if the compiler is optimizing for size, not speed.
Then it becomes very clear which allocation yields the best (smallest)
code. If a compiler optimizes for size however it should give the
option of optimizing for speed as well since they aren't usually
the same. (The PL/I compilers I used to use gave you the option).
-- 
Jim Patterson                              Cognos Incorporated
UUCP:uunet!mitel!cunews!cognos!jimp        P.O. BOX 9707    
PHONE:(613)738-1440 x6112                  3755 Riverside Drive
NOT a Jays fan (not even a fan)            Ottawa, Ont  K1G 3Z4