Hi,
The optimization barrier is defined as
#define barrier() asm volatile ("": : :"memory")
According to the ULK 3rd ed., "a optimization primitive ensures that
the assembly language instructions corresponding to C statements
placed before the primitive are not mixed by the compiler wih assembly
language instruction corresponding to C statements placed after the
primitive. ... The volatile keyword forbids the compiler to reshufle
the asm instruction with the other instructions of the program".
The meaning I get from the above statements is that gcc make
optimizations for the C statements before the barrier and the after
respectively, and the barrier draw a clear line between the two
optimizations. So, the reordering carried out by gcc doesn't cause the
instructions after the barrier move backward beyond the barrier, vice
versa.
However, the gcc manual told me that the optimization made by gcc
does not make our life optimistic. In the following example:
asm volatile("mtfsf 255,%0" : : "f" (fpenv));
sum = x + y;
gcc "may move the addition back before the volatile asm". As far as
some synchronization primitives (e.g. spinlock) are concerned,
optimization barrier is ofen used to ensure that the access to a
shared variable is meant not to be moved prior to a specific
synchonization primitive which protects the shared varialbe. Image
that the following modification to x is moved backward beyond the
spin_lock():
spin_lock(&some_lock);
x = 12345;
Now that a volatile asm can float between the two parts which are
meant to be sperated by itself, I wonder how the keyword 'volatile'
plays it role.
