XFree86 host.def

Bruce Dubbs bdubbs at swbell.net
Thu Oct 3 07:57:03 PDT 2002


Matthias Benkmann wrote:

>On Wed, 2 Oct 2002 16:39:33 -0500 (CDT) dagmar at speakeasy.net wrote:
>
>  
>
>>According to the info pages for gcc...
>>
>>     `-O2' turns on all optional optimizations except for loop
>>     unrolling, function inlining, and register renaming.
>>
>>I'm pretty sure -fomit-frame-pointer is of that lot.
>>    
>>
>
>No, it's not (forget the documentation; it sucks):
>
>long* f(long* p)
>{
>  int i;
>  for (i=0; i<5; ++i) ++p;
>  return p;
>}
>
>compiled with
>
>gcc -O2 -S temp.c
>
>gives
>
>f:
>        pushl   %ebp
>        movl    $4, %edx
>        movl    %esp, %ebp
>        movl    8(%ebp), %eax
>.L6:
>        addl    $4, %eax
>        decl    %edx
>        jns     .L6
>        popl    %ebp
>        ret
>
>but when compiled with
>
>gcc -O2 -fomit-frame-pointer -S temp.c
>
>gives
>
>f:
>        movl    4(%esp), %eax
>        movl    $4, %edx
>.L6:
>        addl    $4, %eax
>        decl    %edx
>        jns     .L6
>        ret
>
>
>Not even -O3 enables -fomit-frame-pointer by default (on x86).
>
Excellent demonstration.  In my mind it brings up the next logical 
question.  How significant is the three extra instructions in each 
function call?  Using the -fomit-frame-pointer omits three instructions 
that will save both time and space with the tradeoff that debuggers will 
be more difficult to use on the code, but are the cpu cycles and size 
going to be noticable?

Without the frame pointer, we are using two memory access instructions, 
pushl %ebp and popl %ebp that combined take up 4 bytes.  The pop may or 
may not have the access in cache, depending on the code in petween and 
of course it they will take up 4 bytes of memory on the stack each time 
the function is called.  The execution time in cycles depends on the 
processor, but  only a register-to-register instruction is faster.

The movl %esp, %ebp is 2 bytes long and is a reg-to-reg instruction, 
which uses no additional memory and is the fastest type of instruction.

The bottom line in my mind is that while omitting the instructions will 
save both time and space, the percentage change in both would not appear 
to be significant.  In any case, more testing on real programs would be 
necessary to measure the actual differences. Testing of execution time 
and static storage would not be hard, but if we wanted to test stack 
size differences, that would be harder.
  -- Bruce

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message



More information about the blfs-dev mailing list