All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Keith Owens <kaos@ocs.com.au>, linux-kernel@vger.kernel.org
Cc: David Zaffiro <davzaffiro@netscape.net>
Subject: Re: Compiling x86 with and without frame pointer
Date: Thu, 21 Nov 2002 09:44:39 -0800	[thread overview]
Message-ID: <224900000.1037900678@flay> (raw)
In-Reply-To: <19005.1037854033@kao2.melbourne.sgi.com>

> The conventional wisdom is that compiling x86 without frame pointer
> results in smaller code.  It turns out to be the opposite, compiling
> with frame pointers results in a smaller kernel.  gcc version 3.2
> 20020822 (Red Hat Linux Rawhide 3.2-4).

I looked at 2.5.47 (with a splattering of performance patches) using 
gcc 2.95.4 (Debian Woody), on a 16-way NUMA-Q, and did some kernel
compile testing. The times to do the tests were almost identical
(within error noise), but the kernel was indeed smaller

   text    data     bss     dec     hex filename
1873293  396231  459388 2728912  29a3d0 2.5.47-mjb1/vmlinux
1427355  396875  455356 2279586  22c8a2 2.5.47-mjb1-frameptr/vmlinux

Wow ... that's quite some difference ;-)

> I use -momit-leaf-frame-pointer for optimization in some own 
> projects, instead of the "-fomit-frame-pointer". For me, this 
> results in better codesize/speed compared to both "-fomit-frame-pointer" 
> or no option at all. Actually gcc-2.95 seems to support this feature 
> as well, but it never made it into the 2.95 docs...

I tried this, but it seemed to be the same as -fomit-frame-pointer
(on 2.95 at least).

Given that omitting the -fomit-frame-pointer makes a smaller kernel,
that's easier to debug, I'd say this is a good thing to do unless someone
can get *negative* benchmark results. 

M.


  parent reply	other threads:[~2002-11-21 17:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-21  4:47 Compiling x86 with and without frame pointer Keith Owens
2002-11-21  5:06 ` Mark Mielke
2002-11-21  9:30   ` David Zaffiro
2002-11-21 19:20     ` Willy Tarreau
2002-11-21 19:32       ` Doug Ledford
2002-11-21 19:41         ` Willy Tarreau
2002-11-21 20:00           ` Doug Ledford
2002-11-25  8:47       ` David Zaffiro
2002-11-25  8:52         ` Willy Tarreau
2002-11-25 14:55           ` Denis Vlasenko
2002-11-25 15:00         ` Denis Vlasenko
2002-11-25 11:57           ` David Zaffiro
2002-11-21 12:55 ` Dave Jones
2002-11-21 14:46   ` Alan Cox
2002-11-21 17:44 ` Martin J. Bligh [this message]
2002-11-21 23:47   ` Rudmer van Dijk
2002-11-25  8:59   ` David Zaffiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=224900000.1037900678@flay \
    --to=mbligh@aracnet.com \
    --cc=davzaffiro@netscape.net \
    --cc=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.