This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is there any other optimization for memory?


2011/7/14 Ian Lance Taylor <iant@google.com>:
> Parmenides <mobile.parmenides@gmail.com> writes:
>
>>>> 2. ?"and not optimize stores or loads to that memory"
>>>> Except caching memory values in registers, is there any other
>>>> optimizaiton for stores or loads to memory?
>>>
>>> Not in this case, I think it's just another way of saying the same
>>> thing.
>>>
>>
>> I think the reordering instructions involving memory operations but
>> not stores or loads might count as some optimization. It seems that a
>> "memory" will prevent gcc from this kind of optimization. If so, would
>> the manual give some statements about it.
>
> I'm sorry, I don't understand what you mean.

For the purpose of understanding some gcc's features, without ideas of
details underlying gcc, I have to code some examples in C and compile
them into assembly code, then observe them to get some ideas. Memory
values caching in registers is one optimization taken by gcc,
reordering instructions is another. A "memory" clobber in an inline
assembly may have influence on the both. I have coded an example in C
to try to understand the former.

int s = 0;
int tst(int lim)
{
     int i;

     for (i = 1; i < lim; i++)
          s = s + i;

     asm volatile(
          "nop"
          );

     s = s * 10;

     return s;
}

To compile the C souce, the following command is excuted.
gcc -S -O tst.c

The corresponding assembly code is as follows:
tst:
        pushl   %ebp
        movl    %esp, %ebp
        movl    8(%ebp), %ecx
        cmpl    $1, %ecx
        jle     .L2
        movl    s, %edx
        movl    $1, %eax
.L4:
        addl    %eax, %edx
        incl    %eax
        cmpl    %eax, %ecx
        jne     .L4
        movl    %edx, s     <--- After the loop, s is write back into memory.
.L2:
        movl    s, %eax     <--- Before the evaluating 's = s * 10', s
is reload into register.
        leal    (%eax,%eax,4), %eax
        addl    %eax, %eax
        movl    %eax, s
        popl    %ebp
        ret

So, the "memory" clobber have prevented the optimization. But for the
latter case, namely reordering instructions, I can not obtain an
example like the above to illustrate how "memory" clobber prevent
reordering instructions. I don't know some circumstances under which
gcc will do reodering. Without them, I can not observe the effect of
the "memory" clobber.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]