All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Andi Kleen <ak@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>, Linus Torvalds <torvalds@osdl.org>,
	Andrew Morton <akpm@osdl.org>,
	Arjan van de Ven <arjan@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 02/2] allow gcc4 to optimize unit-at-a-time
Date: Wed, 28 Dec 2005 09:34:30 -0600	[thread overview]
Message-ID: <20051228153430.GO3356@waste.org> (raw)
In-Reply-To: <p734q4tb5na.fsf@verdi.suse.de>

On Wed, Dec 28, 2005 at 04:30:49PM +0100, Andi Kleen wrote:
> Ingo Molnar <mingo@elte.hu> writes:
> 
> > allow gcc4 compilers to optimize unit-at-a-time - which results in gcc
> > having a wider scope when optimizing. This also results in smaller code
> > when optimizing for size. (gcc4 does not have the stack footprint
> > problem of gcc3 compilers.)
> 
> I never had any trouble with stack footprint even with gcc 3.3 on x86-64
> and unit-at-a-time and it was always enabled. 

The particular offenders I remember were in lib/inflate.c running over
4K well before 4K stacks were in mainline, so I fixed it well before
anyone else got to see it.
 
> But one caveat: turning on unit-at-a-time makes objdump -S / make
> foo/bar.lst with CONFIG_DEBUG_INFO essentially useless because objdump
> cannot deal with functions being out of order in the object file. This
> can be a big problem while analyzing oopses - essentially you have
> to analyze the functions without source level information. And with
> unit-at-a-time they become bigger so it's more difficult.

Yeah, and it also makes stuff like bloat-o-meter output go all to hell.
 
> But I still think it's a good idea.

Indeed.

-- 
Mathematics is the supreme nostalgia of our time.

  reply	other threads:[~2005-12-28 15:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-28 11:47 [patch 02/2] allow gcc4 to optimize unit-at-a-time Ingo Molnar
2005-12-28 12:04 ` Jakub Jelinek
2005-12-28 12:28   ` Sam Ravnborg
2005-12-28 13:04     ` Jakub Jelinek
2005-12-28 12:47       ` Sam Ravnborg
2005-12-28 12:50         ` Sam Ravnborg
2005-12-28 13:06   ` Ingo Molnar
2005-12-28 15:30 ` Andi Kleen
2005-12-28 15:34   ` Matt Mackall [this message]
2005-12-28 15:41   ` Ingo Molnar
2005-12-28 17:46     ` Andreas Kleen

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=20051228153430.GO3356@waste.org \
    --to=mpm@selenic.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@osdl.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.