Parmenides <mobile.parmenides@xxxxxxxxx> writes:
> 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.
That is not precisely correct. As is documented in the gcc manual, "asm
volatile" means that the instruction has side effects which are not
described in the outputs, and thus may not be deleted. The barrier you
describe is not an optimization barrier; it is a memory barrier. gcc
may reorder instructions across the asm. However, because the asm
instruction clobbers "memory", gcc may not reorder instructions which
read or write memory across the asm. It may only reorder instructions
which affect local variables whose addresses are not taken.
(I think that should answer the rest of your message as well.)
Ian
