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