public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: obrien@FreeBSD.org
To: gcc-gnats@gcc.gnu.org
Cc: John Baldwin <jhb@FreeBSD.org>
Subject: optimization/6627: -fno-align-functions regression from 2.95
Date: Fri, 10 May 2002 11:46:00 -0000	[thread overview]
Message-ID: <200205101842.g4AIgo1f083543@dragon.nuxi.com> (raw)


>Number:         6627
>Category:       optimization
>Synopsis:       -fno-align-functions regression from 2.95
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Fri May 10 11:46:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     David O'Brien
>Release:        3.1 20020509 (prerelease) [FreeBSD]
>Organization:
The FreeBSD Project
>Environment:
System: FreeBSD dragon.nuxi.com 5.0-CURRENT FreeBSD 5.0-CURRENT #261: Mon May 6 11:39:49 PDT 2002 rootk@dragon.nuxi.com:/FBSD/src/sys/i386/compile/DRAGON i386


	
host: i386-portbld-freebsd5.0
build: i386-portbld-freebsd5.0
target: i386-portbld-freebsd5.0
configured with: ./..//gcc-20020429/configure --disable-nls --with-gnu-as --with-gnu-ld --with-gxx-include-dir=/opt/gcc31.2002-04-29/lib/gcc-lib/i386-portbld-freebsd5.0/3.1/include/g++ --disable-libgcj --disable-shared --prefix=/opt/gcc31.2002-04-29 i386-portbld-freebsd5.0
>Description:

	from http://gcc.gnu.org/ml/gcc-bugs/2002-05/msg00372.html

We are currently trying to change the system compiler in FreeBSD over
to gcc 3.1.x.  Some of the C code we compile is in the bootstrap where
space is a real premium, thus we want to avoid as much padding as
possible.  Since it's just boot code that isn't executed all that often
the performance hit from making the code more compact (i.e. if it's
misaligned) is much less important than the space taken up by padding.
The problem we are seeing is that -fno-align-functions doesn't seem to
actually be disabling function alignment (and possibly similar for the
other -fno-align-foo parameters).

Using the program below, this is what the current system compiler (2.95.4
turns out:

$ cc -v
Using builtin specs.
gcc version 2.95.4 20020320 [FreeBSD]
$ cc -Os -malign-functions=0 test.c -c
$ objdump -d test.o

test.o:     file format elf32-i386

Disassembly of section .text:

00000000 <foo>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   c9                      leave  
   4:   c3                      ret    

00000005 <bar>:
   5:   55                      push   %ebp
   6:   89 e5                   mov    %esp,%ebp
   8:   c9                      leave  
   9:   c3                      ret    
   a:   89 f6                   mov    %esi,%esi

Note <bar> starts at offset 05 right after <foo>.

This is what a CVS version of gcc 3.1 turns out:

$ gcc31 -v
Reading specs from /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1/specs
Configured with: ./..//gcc-20020429/configure --disable-nls --with-gnu-as
--with-gnu-ld
--with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1/includ
e/g++ --disable-libgcj --disable-shared --prefix=/usr/local
i386-portbld-freebsd5.0
Thread model: posix
gcc version 3.1 20020429 (prerelease) [FreeBSD]
$ gcc31 -Os -malign-functions=0 -c test.c
cc1: warning: -malign-functions is obsolete, use -falign-functions
$ objdump -d test.o

test.o:     file format elf32-i386

Disassembly of section .text:

00000000 <foo>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   c9                      leave  
   4:   c3                      ret    
   5:   90                      nop    

00000006 <bar>:
   6:   55                      push   %ebp
   7:   89 e5                   mov    %esp,%ebp
   9:   c9                      leave  
   a:   c3                      ret    
   b:   90                      nop    

Note the extra 'nop' after <foo> now to force <bar> to be
aligned.  If I use '-fno-align-functions' in place of
'-malign-functions=0' above, I get the same result.

Now a few extra nop's after each function isn't going to
add but so much "bloat" but we have seen a 7k program go from
128 bytes to spare to being 64 bytes too large, which is a
difference of 244 bytes.  As far as I can tell, the difference
in size is due to alignment padding for functions, labels, loops,
etc.

>How-To-Repeat:

void foo(void);
void bar(void);

void
foo(void)
{
}

void
bar(void)
{
}

gcc295 -Os -malign-functions=0 -c test.c
gcc31 -Os -malign-functions=0 -c test.c

>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted:


             reply	other threads:[~2002-05-10 18:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-10 11:46 obrien [this message]
2002-05-13 16:52 rth
2002-06-27 13:36 obrien
2002-06-27 13:38 Gerald Pfeifer
2002-10-02 19:45 sayle

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=200205101842.g4AIgo1f083543@dragon.nuxi.com \
    --to=obrien@freebsd.org \
    --cc=gcc-gnats@gcc.gnu.org \
    --cc=jhb@FreeBSD.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 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).