-fomit-frame-pointer

Message

predatorfreak · Post by **predatorfreak** » Fri Mar 10, 2006 3:01 am

PrakashP wrote:
predatorfreak wrote:
PrakashP wrote:IIRC to free the frame pointer, you need to add a bit of code - for every function doing this trick.
Then OMITTING the frame pointer SHOULD actually decrease the code size. But it does the opposite. Also, the increase seems to be WORSE with C++ applications, e.g rxvt-unicode goes up from 192K to 220K without frame pointers.
Learn a bit of assembler then you'll understand that this is not a contradiction.

Well I stand corrected, I'm not an asm or C developer (well, beyond basics that is), you know.

hielvc · Post by **hielvc** » Fri Mar 10, 2006 5:53 pm

I tried this

Code: Select all

 WITH -FOMIT-FRAME-POINTER
ll /usr/bin/less
-rwxr-xr-x 1 root root 93484 Jan  1 03:41 /usr/bin/less
 
time man bash &>/dev/null

real    0m0.599s
user    0m0.516s
sys     0m0.028s
hielvc@tester ~/testing $ time man bash &>/dev/null

real    0m0.611s
user    0m0.516s
sys     0m0.024s

Remerged with ==> CFLAGS=" -march=athlon-xp -Os -pipe "
ll /usr/bin/less
-rwxr-xr-x 1 root root 92924 Mar 10 09:46 /usr/bin/less

hielvc@tester ~/testing $ time man bash &>/dev/null

real    0m0.567s
user    0m0.504s
sys     0m0.024s
hielvc@tester ~/testing $ time man bash &>/dev/null

real    0m0.576s
user    0m0.528s
sys     0m0.008s

It apears that it might be a tweak faster too.

graphicsMan · Post by **graphicsMan** » Fri Mar 10, 2006 6:24 pm

hielvc wrote:It apears that it might be a tweak faster too.

I think it depends on the kind of application we are talking about. You benchmarked an I/O intensive program (man).

I tried a few experiments with my photon tracer, which is definitely compute bound:

22.8s -O2 -ffastmath
22.0s -O2 -ffastmath -fomit-frame-pointer
16.8s -O2 -ffastmath -msse -mfpmath=sse
15.8s -O2 -ffastmath -fomit-frame-pointer -msse -mfpmath=sse

Obviously using sse instead of x87 is a bigger concern for me, but you'll notice all other things being equal, that fomit-frame-pointer seems to be better for me (for my compute bound program).

Brian

hielvc · Post by **hielvc** » Fri Mar 10, 2006 6:31 pm

That was my thinking in that " Whats good for the gander aint nessisarily good for the goose " It would be to easy if it was black and white

PrakashP · Post by **PrakashP** » Fri Mar 10, 2006 9:10 pm

Of course omitting the frame pointer will probably result in faster code. To test extremes, test

-fomit-frame-pointer

vs

-fPIC

With first one you'll have one additional register, with second one one less, so in all first one has two registers more. (Of course if testing a shared libtool lib won't work as alway fpic is added and on AMD64 shared libs w/o pic won't be possible, so test with an executable, which preferably only links to static libs.)

zomps · Post by **zomps** » Sat Mar 11, 2006 8:27 am

From gcc manual

-fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.

On some machines, such as the VAX, this flag has no effect, because the standard calling sequence automatically handles the frame pointer and nothing is saved by pretending it doesn't exist. The machine-description macro FRAME_POINTER_REQUIRED controls whether a target machine supports this flag. See Register Usage.

Enabled at levels -O, -O2, -O3, -Os.

Why we need enable it, when its turned on all -O flags

PrakashP · Post by **PrakashP** » Sat Mar 11, 2006 9:15 am

It is enabled on machines which allows debugging with it enabled.

predatorfreak · Post by **predatorfreak** » Sun Mar 12, 2006 12:07 pm

PrakashP wrote:It is enabled on machines which allows debugging with it enabled.

and x86 doesn't allow this, as we all know :).

namo · Post by **namo** » Wed May 10, 2006 5:51 am

A question about fomit-frame-pointer and gcc-4.*

http://gcc.gnu.org/gcc-4.0/changes.html wrote:Location lists are now generated by default when compiling with debug info and optimization. Location lists provide more accurate debug info about locations of variables and they allow debugging code compiled with -fomit-frame-pointer

Does it mean I will be able to get meaningful backtraces if I compile with -OX -ggdb ?
Is it still possible with only -OX ?

I tried -Os -ggdb and my bt seemed garbled, but it could be because some of the libraries were compiled with -fomit.

I would appreciate any insight on this !