why the barrier() can not take effect?
Andrew Haley
aph@redhat.com
Wed Dec 22 15:36:00 GMT 2010
On 12/22/2010 03:16 PM, Parmenides wrote:
> Hi,
>
> According to the gcc's manual, in an extended assembly statement,
> if the string "memory" is added to the list of of clobbered registers,
> it will cause "gcc to not keep memory values cached in registers
> across the assembler instrution and not optimize stores or loads to
> that memory". To this end, IMO, after this kind of statement all
> values cached in registers should be write into the corresponding
> memory locations. But, the following example illustrates some
> different thing.
>
> #define barrier() __asm__ __volatile__("": : :"memory")
>
> int main()
> {
> int i, n;
> int s = 0;
>
> scanf("%d",&n);
> for (i = 0; i< n; i++)
> s += i;
> barrier();
> printf("%d\n", s);
>
> return 0;
> }
>
> # gcc -S -O tst.c
>
> We get the assembly code like this:
>
> leal -8(%ebp), %eax
> pushl %eax
> pushl $.LC0
> call scanf
> movl -8(%ebp), %edx<--- cache n into edx
> addl $16, %esp
> testl %edx, %edx
> jg .L2
> movl $0, %ecx
> jmp .L4
> .L2:
> movl $0, %eax<--- cache i into eax
> movl $0, %ecx<--- cache s into ecx
> .L5:
> addl %eax, %ecx
> incl %eax
> cmpl %eax, %edx
> jne .L5
> .L4:
> <--- at this point, I think the barrier() will cause the values cached
> in edx, eax and ecx will be write back to n, i, and s, respectively.
> But, this is not really the case.
>
> subl $8, %esp
> pushl %ecx
> pushl $.LC1
> call printf
Well, i and s never have their address taken, so they are not forced
into memory, and the memory clobber can't affect them.
Andrew.
More information about the Gcc-help
mailing list