-fomit-frame-pointer [was: Re: XFree86 host.def]

Greg Schafer gschafer at zip.com.au
Thu Oct 3 16:07:11 PDT 2002

On Fri, Oct 04, 2002 at 12:54:04AM +0200, Matthias Benkmann wrote:
> Okay. I think the numbers speak for themselves. But now for the real fun.
> I know there are a lot of you optimization freaks out there who compile
> everything with -O3. I've argued against this in the past
> (http://archive.linuxfromscratch.org/mail-archives/lfs-support/2002/09/03
> 57.html) but I know no one's listening. Well, here's what you get:
> /tmp> gcc -O3 temp2.c -o temp2
> /tmp> time ./temp2
> real    0m55.612s
> user    0m55.610s
> sys     0m0.000s
> /tmp> gcc -O3 -fomit-frame-pointer temp2.c -o temp2
> time ./temp2
> real    0m55.611s
> user    0m55.610s
> sys     0m0.000s
> LMAO. Not only is -O3 3 seconds slower, it even loses all the benefits of
> -fomit-frame-pointer. I just love it. Now all of you speed freaks will
> have to rebuild your LFSs or live with the feeling that with all of the
> CFLAGS fiddling not only have you sacrificed stability but you may even
> have lost speed. ROTFL. :-)
> BTW, the numbers get only a little better with -march=k6 (and adding all
> the flags suggested in the Mozilla hint). The whole situation may be
> different on a Pentium or with a different GCC version (I have 3.2) but
> the point is (and this has also been mentioned on the gcc mailing list,
> btw) that -O3 may produce much worse code than -O2.
> The interesting thing is that the code generated for foo() is the same
> with -O3 -fomit-frame-pointer and -O2 -fomit-frame-pointer. The difference
> is that -O3 inlines foo() into main() but because the frame pointer of
> main() apparently can't be omitted, the inlined code is worse because of
> fewer available registers. So this example debunks the common myth that
> inlining is always a good idea.

Excellent work MSB. I've been advocating the "-O3 is worse than -O2" line
for a while now as well. But my tests weren't quite as scientific as yours,
just some simple gzip decompression tests.

So, at least one person has been listening! :)

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