In article <c0**********@news-reader3.wanadoo.fr>
jacob navia <ja***@jacob.remcomp.fr> writes:
Consider:
static int a;
int fn(void)
{
a = a+1;
// sequence point <S> here
return a;
}
The compiler is supposed to have done the assignment when
the sequence point <S> is reached. If the variable is cached
in a register that is not the case.
Here the variable "a" has file scope and internal linkage. A
C compiler would be allowed to rewrite the code as:
int fn(void) {
static int a;
register int temp = a;
... do all the work in temp ...
a = temp;
return a;
}
*if* it can prove that no other code in this translation unit
refers to this same object "a".
(The original code in fn() is short and simple enough that this
transformation would likely gain nothing as is, but if the code
were more complex than just "a = a + 1" it might be worthwhile.
Similar arguments apply if the code in fn() is hoisted into its
callers -- but note that fn() itself has file scope and external
linkage, so unless compilation is done at link time, there must
be a "vanilla version" accompanying the inline expanded versions.)
If fn() calls other functions which might drop back into "this
translation unit" and refer to the same "a", then the register
caching can *still* occur provided the cached value is stored
back into "memory" before and after those points. The variable
"a" may need to move back to file scope (from the block scope I
gave it above). If "a"'s address is never taken (or if the CPU
provides &cpuregister in hardware, as a few do) it would be
legal to use a "global CPU register" for the variable "a".
The "Big Hammer spelled volatile" is the way to tell a compiler
"please do not make provably-correct-according-to-the-Standard
optimizations", as one might need for multi-threaded code here. :-)
Most compilers simply do not bother attempting to optimize in these
cases, though, as the list of exceptions to "allowed register
shadowing" gets complicated quickly, and in most cases I suspect
there is not much benefit.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it
http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.