🚀 go-pugleaf

In article <1992Nov19.034325.3864@technix.mn.org> bret@technix.mn.org (Bret Indrelee) writes:

>    In article <id.HJ1V.BTG@ferranti.com> peter@ferranti.com (peter da silva) writes:
>    >In article <BxtA6v.CE8@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>    >> But it is.  The operations often use register arguments and the results
>    >> are wanted in registers.
>    >
>    >What's a register? Most modern compilers ignore "register", or use it as a
>    >hint "this is a frequently used value".
>    >
>    >And how is an inline library part of the language more than a subroutine
>    >or an include file?
> 
>    Which brings up a question I've wondered about.  Do any compilers use
>    'register' to indicate that a pointer reference DOESN'T access the
>    value?
> 
>    If so, it once again becomes usefull to use the register keyword,
>    as a no-alias.  Compiler could optimize knowing that the value isn't
>    changed by that weird intervening pointer reference.

There are two separate issues here.  One is a minor point for language
lawyers.  There is some semantic content to C's "register" declaration,
namely that it is illegal to take the address of a "register" variable.

Which leads to the optimization issue.  Compilers don't have to be
completely pessimistic about what might be changed by pointer references.
With a suitable definition of what it means for a variable to have its
address taken, pointer references can only change those variables that
have had their addresses taken.

So, while it is true that register variables may lead to better optimization,
that is because they never have their addresses taken.  So, with a compiler
that keeps track of which variables have their addresses taken, the
performance improvements resulting from the use of register variables remain,
even after you delete the "register" declaration.
--
                                   Dan Prener (prener@watson.ibm.com)