On 11/04/2011 23:42, Ian Lance Taylor wrote:
The definition of "memory barrier" is ambiguous when looking at code
written in a high-level language.
The statement "asm volatile ("" : : : "memory");" is a compiler
scheduling barrier for all expressions that load from or store values to
memory. That means something like a pointer dereference, an array
index, or an access to a volatile variable. It may or may not include a
reference to a local variable, as a local variable need not be in
memory.
Is there any precise specifications for what counts as "memory" here?
As gcc gets steadily smarter, it gets harder to be sure that
order-specific code really is correctly ordered, while letting the
compiler do it's magic on the rest of the code. I work with embedded
systems - it's not uncommon to have to deal with things like
interrupt-disabled sections which should be as short and fast as
possible, but no shorter!
For example, if you have code like this:
static int x;
void test(void) {
x = 1;
asm volatile ("" : : : "memory");
x = 2;
}
The variable "x" is not volatile - can the compiler remove the
assignment "x = 1"? Perhaps with aggressive optimisation, the compiler
will figure out how and when x is used, and discover that it doesn't
need to store it in memory at all, but can keep it in a register
(perhaps all uses have ended up inlined inside the same function). Then
"x" is no longer in memory - will it still be affected by the memory
clobber?
Also, is there any way to specify a more limited clobber than just
"memory", so that the compiler has as much freedom as possible? Typical
examples are to specify "clobbers" for just certain variables, leaving
others unaffected, or to distinguish between reads and writes. For
example, you might want to say "all writes should be completed by this
point, but data read into registers will stay valid".
Some of this can be done with volatile accesses in different ways, but
not always optimally, and not always clearly.
