public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jamie Lokier <egcs@tantalophile.demon.co.uk>
To: Richard Henderson <rth@redhat.com>,
	Marc.Espie@liafa.jussieu.fr, gcc@gcc.gnu.org
Subject: Re: [GCC 3.0] Bad regression, binary size
Date: Sat, 07 Jul 2001 14:41:00 -0000	[thread overview]
Message-ID: <20010707234148.C10109@pcep-jamie.cern.ch> (raw)
In-Reply-To: <20010707130928.A2761@redhat.com>

Richard Henderson wrote:
> > -rwxr-xr-x   1 espie    wheel     3994332 Jul  5 16:08 bsd
> > 
> > 3.0:
> > -rwxr-xr-x   1 espie    wheel     4068067 Jul  5 16:35 bsd
> > 
> > Exact same source. Both are using -O2 -Os to compile.
> 
> Also try -mpreferred-stack-boundary=2.  The default is 16 byte
> alignment, which your kernel almost certainly doesn't need, and
> there is extra code to maintain that alignment.

By the way, is this 16 byte stack alignment going to be a permanent
feature?

As far as I can tell, it is not necessary to 16-byte align all functions
just to help the performance of a few.  Instead, functions which pass
aligned arguments or use aligned locals, and which don't receive any
aligned argument, could use "and" to align the stack themselves.  It is
necessary to record the original stack pointer, but that is easy enough.

(The one case where this rule isn't perfect is variadic functions, but
alignment-related performance is not really an issue for those).

It seems to me this would improve performance, code density, and reduce
stack usage of functions which do not need the extra alignment, while at
the same time allow functions which do benefit from stack alignment to
perform as well as they do now.

This would also have the benefit that if a larger alignment is required
for some object, for example some structures like to be cache-line
aligned, then that can be accomodated too.

cheers,
-- Jamie

  reply	other threads:[~2001-07-07 14:41 UTC|newest]

Thread overview: 121+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-05  7:39 Marc Espie
2001-07-05  7:51 ` Marc Espie
2001-07-05  8:07   ` Joern Rennecke
2001-07-05  8:12     ` Marc Espie
2001-07-05  8:17   ` David Edelsohn
2001-07-05  8:22     ` Marc Espie
2001-07-05 15:14 ` Geoff Keating
2001-07-07 13:09 ` Richard Henderson
2001-07-07 14:41   ` Jamie Lokier [this message]
2001-07-07 16:45     ` Richard Henderson
2001-07-08 14:28       ` Linus Torvalds
2001-07-08 23:59         ` Marc Espie
2001-07-09  6:06           ` Tim Prince
2001-07-09  9:10           ` Linus Torvalds
2001-07-09  9:28             ` Marc Espie
2001-07-09  9:58               ` Linus Torvalds
2001-07-09 10:10             ` Paolo Carlini
2001-07-09 14:49         ` Richard Henderson
2001-07-09 15:23           ` Linus Torvalds
2001-07-09 15:55             ` Joern Rennecke
2001-07-09 16:14               ` Linus Torvalds
2001-07-09 16:05             ` Richard Henderson
2001-07-09 16:24               ` Linus Torvalds
2001-07-12  8:41 ` size_t printf warnings and preprocessor Marc Espie
2001-07-12  8:49   ` Andreas Jaeger
2001-07-12  8:52     ` Marc Espie
2001-07-12  8:54       ` Andreas Jaeger
2001-07-12  9:10   ` Joseph S. Myers
  -- strict thread matches above, loose matches on Subject: below --
2001-07-23 19:42 [GCC 3.0] Bad regression, binary size dewar
2001-07-24  9:27 ` Linus Torvalds
2001-07-23  4:46 Jonathan Thornburg
2001-07-23 15:14 ` Linus Torvalds
2001-07-09 10:13 dewar
2001-07-09 10:37 ` Linus Torvalds
2001-07-09  7:50 dewar
2001-07-09  7:18 dewar
2001-07-09  7:22 ` Marc Espie
2001-07-05  8:42 dewar
2001-07-09  0:06 ` Marc Espie
2001-07-09 13:12   ` Gerald Pfeifer
2001-07-09 13:28     ` Neil Booth
2001-07-09 14:13       ` Gerald Pfeifer
2001-07-09 14:36         ` Bobby McNulty
2001-07-09 14:54       ` Justin Guyett
2001-07-09 14:59         ` Phil Edwards
2001-07-09 15:04           ` Marc Espie
2001-07-09 16:43           ` Daniel Berlin
2001-07-05  8:31 dewar
2001-07-05  8:38 ` Marc Espie
1999-09-13 21:45 type based aliasing again N8TM
1999-09-14  4:01 ` Marc Espie
1999-09-14  9:56   ` David Edelsohn
1999-09-14 10:10     ` Richard Earnshaw
1999-09-14 10:31       ` Nick Ing-Simmons
1999-09-14 10:52         ` David Edelsohn
1999-09-14 11:11           ` craig
1999-09-14 14:44             ` David Edelsohn
1999-09-30 18:02               ` David Edelsohn
1999-09-14 15:06             ` David Edelsohn
1999-09-14 17:35               ` Marc Lehmann
1999-09-30 18:02                 ` Marc Lehmann
1999-09-14 23:41               ` craig
1999-09-15  8:28                 ` Marc Lehmann
1999-09-30 18:02                   ` Marc Lehmann
1999-09-15  9:19                 ` David Edelsohn
1999-09-15  9:59                   ` Nick Ing-Simmons
1999-09-15 15:33                     ` David Edelsohn
1999-09-30 18:02                       ` David Edelsohn
1999-09-30 18:02                     ` Nick Ing-Simmons
1999-09-15 10:01                   ` craig
1999-09-30 18:02                     ` craig
1999-09-30 18:02                   ` David Edelsohn
1999-09-30 18:02                 ` craig
1999-09-30 18:02               ` David Edelsohn
1999-09-30 18:02             ` craig
1999-09-14 11:58           ` Gerald Pfeifer
1999-09-30 18:02             ` Gerald Pfeifer
1999-09-30 18:02           ` David Edelsohn
1999-09-14 11:01         ` craig
1999-09-14 11:14           ` craig
1999-09-30 18:02             ` craig
1999-09-14 11:39           ` Mark Mitchell
1999-09-14 14:48             ` Toon Moene
1999-09-14 15:00               ` David Edelsohn
1999-09-14 16:01                 ` Toon Moene
1999-09-14 16:15                   ` David Edelsohn
1999-09-14 16:43                     ` Mark Mitchell
1999-09-30 18:02                       ` Mark Mitchell
1999-09-14 17:39                     ` Marc Lehmann
1999-09-30 18:02                       ` Marc Lehmann
1999-09-30 18:02                     ` David Edelsohn
1999-09-14 16:19                   ` dvv
1999-09-14 17:38                     ` Michael Meissner
1999-09-30 18:02                       ` Michael Meissner
1999-09-30 18:02                     ` Dima Volodin
1999-09-30 18:02                   ` Toon Moene
1999-09-30 18:02                 ` David Edelsohn
1999-09-14 15:08               ` Mark Mitchell
1999-09-30 18:02                 ` Mark Mitchell
1999-09-30 18:02               ` Toon Moene
1999-09-30 18:02             ` Mark Mitchell
1999-09-30 18:02           ` craig
1999-09-14 23:46         ` Geoff Keating
1999-09-15  7:47           ` Nick Ing-Simmons
1999-09-30 18:02             ` Nick Ing-Simmons
1999-09-30 18:02           ` Geoff Keating
1999-09-30 18:02         ` Nick Ing-Simmons
1999-09-30 18:02       ` Richard Earnshaw
1999-09-14 17:22     ` Marc Lehmann
1999-09-30 18:02       ` Marc Lehmann
1999-09-30 18:02     ` David Edelsohn
1999-09-14 17:23   ` Marc Lehmann
1999-09-15  1:59     ` Marc Espie
1999-09-15  8:28       ` Marc Lehmann
1999-09-30 18:02         ` Marc Lehmann
1999-09-30 18:02       ` Marc Espie
1999-09-30 18:02     ` Marc Lehmann
1999-09-15  2:01   ` Jeffrey A Law
1999-09-30 18:02     ` Jeffrey A Law
1999-09-30 18:02   ` Marc Espie
1999-09-30 18:02 ` N8TM

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=20010707234148.C10109@pcep-jamie.cern.ch \
    --to=egcs@tantalophile.demon.co.uk \
    --cc=Marc.Espie@liafa.jussieu.fr \
    --cc=gcc@gcc.gnu.org \
    --cc=rth@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).