Re: Is there a way to flush registers and tell the C compiler to refill?
- From: Kaz Kylheku <kkylheku@xxxxxxxxx>
- Date: Thu, 19 Mar 2009 23:30:16 +0000 (UTC)
On 2009-03-19, Emmanuel Stapf [ES] <manus_no_spam@xxxxxxxxxxxxxxxxx> wrote:
Hi,
Because using volatile would prevent some C compilation optimization,
I'm looking at an alternative where I would inform the C compiler that
from known points in my program code, no values are in registers and
thus the generated code should refetch the data from memory (and then
use register whenever it can).
There is no such interface in C. But using external functions may achieve this
on many compilers.
For example,
struct complex_struct s {
int value;
};
you mean:
struct complex_struct { ... } s;
void f () {
int i;
i = s.value + s.value; /* 1 */
routine_that_will_indirectly_modify_s_value(); /* 2 */
i = s.value + s.value; /* 3 */
}
Note that if the routine modifes s in a correct, well-defined way, then there
is nothing to worry about (other than a broken compiler). Such a caching
optimization applied blindly is forbidden. A sequence point occurs immediately
before the function call, and the function must see the stable value of object
s. A sequence point occurs before the function returns also.
So even if the aggressive caching is done, it must be done in such a way that
the routine can see the cached value. If it cannot be ensured that the routine
can used the cached value, then the caching cannot be done.
But the name of your function hints at the fact that s is somehow manipulated
indirectly, like through some aliased pointer or some such thing. In that case,
you are on your own, because the behavior is undefined. The language has no
interface by which you can say ``please do not cache this value''.
However, what you may be able to rely on is making the function external to
your translation unit, and also giving the variable s external linkage.
These facts taken together will forbid most compilers from making any caching
optimizations on s.
This is because the external function has access to the variable and can change
it arbitrarily.
Caching s in spite of this would require global program optimization: code
optimization and generation would have to be delayed until the point when the
program is being linked, at which time it could be proven that the external
function does not touch the variable, and the code could be optimized
accordingly before the final link.
Unless you have this kind of toolchain, this solution should be good enough.
Most C compilers do a more or less complete job of generating the code in
complete isolation, and the final linking stages only resolve the external
references to objects and functions, without rewriting any code in any
significant way.
If I was making volatile, then all accesses to `s.value' would be
penalized and I don't want that.
volatile is a poorly-defined stupidity which should be confined to only the
documented, required ISO C uses: declaring the type of a flag set by an
asynchronous signal handler to be of type ``volatile sig_atomic_t'',
and applying the volatile qualification on local variables that are modified
between setjmp and longjmp whose values are used after the longjmp.
volatile has no other uses that can be relied upon to be portable. For any
specific assurances, you want to use the appropriate compiler extension, if you
have it, or write in assembly language, etc.
.
- References:
- Is there a way to flush registers and tell the C compiler to refill?
- From: Emmanuel Stapf [ES]
- Is there a way to flush registers and tell the C compiler to refill?
- Prev by Date: Re: Binary tree
- Next by Date: Re: Binary tree
- Previous by thread: Re: Is there a way to flush registers and tell the C compiler to refill?
- Next by thread: Re: Is there a way to flush registers and tell the C compiler to refill?
- Index(es):
Relevant Pages
|
