Long term code compactness regression

Long term code compactness regression

[Aaron Lehmann]

I compiled the Linux software package busybox with three different
compiler versions on i386.

compiler        opt     size
gcc 2.7.2.3     -O2     213116
gcc 2.95.4-pre  -Os     216652
gcc 3.0.2-pre   -Os     222012

Binaries were stripped, and the .note and .comment sections were
removed.

This is indicating that gcc 2.7.2.3 does *better* with -O2 than 2.95
and 3.x with -Os. If I broke these down to specific testcases and
compared the assembly output, would anyone look at fixing the behavior
of -Os?

Re: Long term code compactness regression

[Jan Hubicka]

> I compiled the Linux software package busybox with three different
> compiler versions on i386.
> 
> compiler        opt     size
> gcc 2.7.2.3     -O2     213116
> gcc 2.95.4-pre  -Os     216652
> gcc 3.0.2-pre   -Os     222012
> 
> Binaries were stripped, and the .note and .comment sections were
> removed.
> 
> This is indicating that gcc 2.7.2.3 does *better* with -O2 than 2.95
> and 3.x with -Os. If I broke these down to specific testcases and
> compared the assembly output, would anyone look at fixing the behavior
> of -Os?
Some of work has been already done at 3.1.x branch. See Andreas tester
http://www.suse.de/~aj/SPEC for development of size of binaries on mainline
that is mostly decreasing.

For i386, you may try -mpreferred-stack-boundary=2 that is the most common
cause of code size growth on 2.95.0+ compilers for i386.

In case you notice some simple enought testcases to fix, I would happily
look at it, as code size is definitly important parameter, but it would be
nice if you did it for mainline, as 3.0.x branch is not here to fix such
a problems.

Honza

Re: Long term code compactness regression

[Aaron Lehmann]

On Sat, Oct 27, 2001 at 12:46:52AM +0200, Jan Hubicka wrote:
> For i386, you may try -mpreferred-stack-boundary=2 that is the most common
> cause of code size growth on 2.95.0+ compilers for i386.

I ran my tests again with -mpreferred-stack-boundary=2 where
available.

gcc version		options								size
2.7.2.3			-O2									214284
3.0.2			-O2 -mpreferred-stack-boundary=2	212844
2.95.4-pre		-O2	-mpreferred-stack-boundary=2	204076
HEAD			-O2 -mpreferred-stack-boundary=2	202616

Well, that is looking better!

I did have the problem that gcc from HEAD ICE'd on telnet.c:

/usr/local/gcc/bin/gcc -I /home/aaronl/src/busybox/newbus/include -Wall -Wstrict-prototypes -Wshadow -Os -fomit-frame-pointer -D_GNU_SOURCE  -mpreferred-stack-boundary=2   -c -o telnet.o telnet.c
[snip warnings]
telnet.c: In function `telnet_main':
telnet.c:627: Internal compiler error in eliminate_regs, at reload1.c:2576
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.

I wanted to submit the preprocessed source, but, oddly, the problem
does not occur when I preprocess the source using cpp. When I used gcc
-E, the preprocessed source did exhibit the problem. I ran diff on the
two outputs and it seems that only gcc -E would expand things such as
htons():

-        addr->sin_port = htons(port);
+        addr->sin_port = (__extension__ ({ register unsigned short int __v; if (__builtin_constant_p (port)) __v = ((((port) >> 8) & 0xff) | (((port) & 0xff) << 8)); else __asm__ __volatile__ ("rorw $8, %w0" : "=r" (__v) : "0" ((unsigned short int) (port)) : "cc"); __v; %})); 

I'm not sure why, but I've put the one that does exhibit the problem
up at http://people.debian.org/~aaronl/telnet.gcc-E.i.gz . It will
cause an ICE when compiled with -O[23s], on gcc 3.1 20011026
(experimental).

Re: Long term code compactness regression

[Aaron Lehmann]

On Fri, Oct 26, 2001 at 05:35:30PM -0700, Aaron Lehmann wrote:
> I'm not sure why, but I've put the one that does exhibit the problem
> up at http://people.debian.org/~aaronl/telnet.gcc-E.i.gz . It will
> cause an ICE when compiled with -O[23s], on gcc 3.1 20011026
> (experimental).

Below is a much more compact, standalone version that makes a good
testcase:

typedef struct
{
    long fds_bits[32];
} fd_set;

void testfunc(char* foo, int bar)
{
        fd_set readfds;
        fd_set rfds = readfds;

        switch (bar)
        {
                case 0:
                        break;
                default:
                        if ((__extension__ ({register char __result; __asm__ __volatile__ ("btl %1,%2 ; setcb %b0" : "=q" (__result) : "r" (0), "m" (*(&rfds)->fds_bits) : "cc"); __result; })))
                                break;
        }
}

Re: Long term code compactness regression

[Aaron Lehmann]

On Fri, Oct 26, 2001 at 05:35:30PM -0700, Aaron Lehmann wrote:
> 3.0.2			-O2 -mpreferred-stack-boundary=2	212844
> 2.95.4-pre		-O2 -mpreferred-stack-boundary=2	204076
> HEAD			-O2 -mpreferred-stack-boundary=2	202616

s/-O2/-Os/ for all of these. Whoops.

Re: [BusyBox] Re: Long term code compactness regression

[David Schleef]

On Sat, Oct 27, 2001 at 02:20:26AM -0700, Aaron Lehmann wrote:
> On Fri, Oct 26, 2001 at 05:35:30PM -0700, Aaron Lehmann wrote:
> > 3.0.2			-O2 -mpreferred-stack-boundary=2	212844
> > 2.95.4-pre		-O2 -mpreferred-stack-boundary=2	204076
> > HEAD			-O2 -mpreferred-stack-boundary=2	202616
> 
> s/-O2/-Os/ for all of these. Whoops.
> 

This raises the question: why doesn't -Os imply
-mpreferred-stack-boundary=2?



dave...

Re: [BusyBox] Re: Long term code compactness regression

[Paolo Carlini]

David Schleef wrote:

> On Sat, Oct 27, 2001 at 02:20:26AM -0700, Aaron Lehmann wrote:
> > On Fri, Oct 26, 2001 at 05:35:30PM -0700, Aaron Lehmann wrote:
> > > 3.0.2                       -O2 -mpreferred-stack-boundary=2        212844
> > > 2.95.4-pre          -O2 -mpreferred-stack-boundary=2        204076
> > > HEAD                        -O2 -mpreferred-stack-boundary=2        202616
> >
> > s/-O2/-Os/ for all of these. Whoops.
> >
>
> This raises the question: why doesn't -Os imply
> -mpreferred-stack-boundary=2?

It will in 3.1, see this recent checkin by Alexandre Oliva:

    http://gcc.gnu.org/ml/gcc-cvs/2001-10/msg00511.html

Cheers,
Paolo.

Re: [BusyBox] Re: Long term code compactness regression

[Tim Prince]

So, will we retain the option of setting an aligned stack along with -Os
?  On most of my applications, -Os together with -funroll-loops and
aligned data is the fastest running combination for ia32, by a large
margin.
----- Original Message -----
From: "Paolo Carlini" <pcarlini@unitus.it>
To: "David Schleef" <ds@schleef.org>
Cc: <gcc@gcc.gnu.org>
Sent: Sunday, October 28, 2001 5:11 AM
Subject: Re: [BusyBox] Re: Long term code compactness regression


> David Schleef wrote:
>
> > On Sat, Oct 27, 2001 at 02:20:26AM -0700, Aaron Lehmann wrote:
> > > On Fri, Oct 26, 2001 at 05:35:30PM -0700, Aaron Lehmann wrote:
> > > > 3.0.2                       -O2 -mpreferred-stack-boundary=2
212844
> > > > 2.95.4-pre          -O2 -mpreferred-stack-boundary=2
204076
> > > > HEAD                        -O2 -mpreferred-stack-boundary=2
202616
> > >
> > > s/-O2/-Os/ for all of these. Whoops.
> > >
> >
> > This raises the question: why doesn't -Os imply
> > -mpreferred-stack-boundary=2?
>
> It will in 3.1, see this recent checkin by Alexandre Oliva:
>
>     http://gcc.gnu.org/ml/gcc-cvs/2001-10/msg00511.html
>
> Cheers,
> Paolo.
>
>

Re: [BusyBox] Re: Long term code compactness regression

[Jan Hubicka]

> So, will we retain the option of setting an aligned stack along with -Os
Not.
currently the mainline contains patch to default stack alignment to 2 if
-Os is present I am not quite happy about.
You can still pass -Os and overwrite the alignment by -mpreferred-stack-bodary=4
> ?  On most of my applications, -Os together with -funroll-loops and
> aligned data is the fastest running combination for ia32, by a large
> margin.
Do you have any idea why this happends? We should really keep -O2 faster
than -Os in most cases.
I've done some work on the mainline to avoid code bloat in -O2 mode, so
maybe the score is better now.

Honza

Re: [BusyBox] Re: Long term code compactness regression

[Tim Prince]

----- Original Message -----
From: "Jan Hubicka" <jh@suse.cz>
To: "Tim Prince" <tprince@computer.org>
Cc: "Paolo Carlini" <pcarlini@unitus.it>; "David Schleef"
<ds@schleef.org>; <gcc@gcc.gnu.org>
Sent: Sunday, October 28, 2001 9:08 AM
Subject: Re: [BusyBox] Re: Long term code compactness regression


> > So, will we retain the option of setting an aligned stack along
with -Os
> Not.
> currently the mainline contains patch to default stack alignment to 2
if
> -Os is present I am not quite happy about.
> You can still pass -Os and overwrite the alignment
by -mpreferred-stack-bodary=4
> > ?  On most of my applications, -Os together with -funroll-loops and
> > aligned data is the fastest running combination for ia32, by a large
> > margin.
> Do you have any idea why this happends? We should really keep -O2
faster
> than -Os in most cases.
> I've done some work on the mainline to avoid code bloat in -O2 mode, so
> maybe the score is better now.
>
> Honza

I checked this morning, with last week's gcc-3.1 snapshot.  A few cases
with g77 have slowed down in recent weeks.  The worst examples of
slowness with g77 -O2 involve the generation of redundant pointers, as we
have discussed before.  I see -Os faster than -O2 in the same tests
on -msse2 and on -march=pentiumpro.

Re: [BusyBox] Re: Long term code compactness regression

[Jan Hubicka]

> I checked this morning, with last week's gcc-3.1 snapshot.  A few cases
> with g77 have slowed down in recent weeks.  The worst examples of
In what testcases g77 slowed down recently?

Honza
> slowness with g77 -O2 involve the generation of redundant pointers, as we
> have discussed before.  I see -Os faster than -O2 in the same tests
> on -msse2 and on -march=pentiumpro.

Re: [BusyBox] Re: Long term code compactness regression

[Tim Prince]

----- Original Message -----
From: "Jan Hubicka" <jh@suse.cz>
To: "Tim Prince" <tprince@computer.org>
Cc: "Jan Hubicka" <jh@suse.cz>; "Paolo Carlini" <pcarlini@unitus.it>;
"David Schleef" <ds@schleef.org>; <gcc@gcc.gnu.org>
Sent: Sunday, October 28, 2001 10:33 AM
Subject: Re: [BusyBox] Re: Long term code compactness regression


> > I checked this morning, with last week's gcc-3.1 snapshot.  A few
cases
> > with g77 have slowed down in recent weeks.  The worst examples of
> In what testcases g77 slowed down recently?
>
The Livermore Fortran Kernels 4 and 10 both slowed down more than 15%
since 6 weeks ago, with gcc-3.1 on my P-III laptop.  Kernel 8 is the
worst example where -O2 is slower than -Os.  Kernel 10 also is slower
at -O2.  I'll look more closely at this when I have time.

Re: [BusyBox] Re: Long term code compactness regression

[Paolo Carlini]

Jan Hubicka wrote:

> > I checked this morning, with last week's gcc-3.1 snapshot.  A few cases
> > with g77 have slowed down in recent weeks.  The worst examples of
> In what testcases g77 slowed down recently?
>
> Honza

Jan, sorry for my pedantry, but I have ready at hand a very short and basic
c++ testcode (reduced from the Haney tests) which today is 2 times (!) slower
than one week ago on i686 (-O2)... Do you have time to look a little bit at
it? Here it is (PR4714 for some more details):

///////////////////////////////////////////////
class RealMatrix {
public:

  float &index(int i, int j)
    {
      return d[i - 1 + n[0] * (j - 1)];
    }
  float index(int i, int j) const
    {
      return d[i - 1 + n[0] * (j - 1)];
    }

  int dim(int i) const { return n[i - 1]; }

private:

  float *d;
  int n[4];
};

void rmatMul(RealMatrix &t, const RealMatrix &a, const RealMatrix &b)
{
  const int M = a.dim(1), N = b.dim(2), K = b.dim(1);

  for (int j = 1; j <= N; j++)
    {
      for (int k = 1; k <= K; k++)
        {
          float temp = b.index(k, j);
          if (temp != 0.0)
            {
              for (int i = 1; i <= M; i++)
                t.index(i, j) += temp * a.index(i, k);
            }
        }
    }
}
/////////////////////////////////////////

Thanks,
Paolo.

Re: Long term code compactness regression

[Marcus Meissner]

On Fri, Oct 26, 2001 at 03:09:38PM -0700, Aaron Lehmann wrote:
> I compiled the Linux software package busybox with three different
> compiler versions on i386.
> 
> compiler        opt     size
> gcc 2.7.2.3     -O2     213116
> gcc 2.95.4-pre  -Os     216652
> gcc 3.0.2-pre   -Os     222012
> 
> Binaries were stripped, and the .note and .comment sections were
> removed.
> 
> This is indicating that gcc 2.7.2.3 does *better* with -O2 than 2.95
> and 3.x with -Os. If I broke these down to specific testcases and
> compared the assembly output, would anyone look at fixing the behavior
> of -Os?

Following patch might help if there are longer strings.

Without it, gcc will align all strings longer than 31 characters at
a 32 BYTE boundary.

Ciao, Marcus

--- gcc-2.95.2/gcc/config/i386/i386.h.size	Thu Oct 18 10:29:01 2001
+++ gcc-2.95.2/gcc/config/i386/i386.h	Thu Oct 18 10:29:47 2001
@@ -454,7 +454,7 @@
 	? 128								\
 	: (ALIGN))							\
     : TREE_CODE (EXP) == STRING_CST					\
-    ? ((TREE_STRING_LENGTH (EXP) >= 31 && (ALIGN) < 256)		\
+    ? (!optimize_size  && ((TREE_STRING_LENGTH (EXP) >= 31 && (ALIGN) < 256)) \
 	? 256								\
 	: (ALIGN))							\
     : (ALIGN))

Re: [BusyBox] Re: Long term code compactness regression

[Jan Hubicka]

> 
> ----- Original Message -----
> From: "Jan Hubicka" <jh@suse.cz>
> To: "Tim Prince" <tprince@computer.org>
> Cc: "Jan Hubicka" <jh@suse.cz>; "Paolo Carlini" <pcarlini@unitus.it>;
> "David Schleef" <ds@schleef.org>; <gcc@gcc.gnu.org>
> Sent: Sunday, October 28, 2001 10:33 AM
> Subject: Re: [BusyBox] Re: Long term code compactness regression
> 
> 
> > > I checked this morning, with last week's gcc-3.1 snapshot.  A few
> cases
> > > with g77 have slowed down in recent weeks.  The worst examples of
> > In what testcases g77 slowed down recently?
> >
> The Livermore Fortran Kernels 4 and 10 both slowed down more than 15%
> since 6 weeks ago, with gcc-3.1 on my P-III laptop.  Kernel 8 is the
> worst example where -O2 is slower than -Os.  Kernel 10 also is slower
> at -O2.  I'll look more closely at this when I have time.
Richard made some changes to strength reduction.  I guess the analyzis
behaves crazilly that causes strength reduction to do nasty thinks.

I've made some improvements to early dead code removal as side effect
of my webizer pass, but it looks that it will not get in, as it can
get obsoletted by SSA, but thats behind 3.1 horizont...

I will try to compare the difference. 
Thanks for letting me know!

Honza

Re: [BusyBox] Re: Long term code compactness regression

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> > > I checked this morning, with last week's gcc-3.1 snapshot.  A few cases
> > > with g77 have slowed down in recent weeks.  The worst examples of
> > In what testcases g77 slowed down recently?
> >
> > Honza
> 
> Jan, sorry for my pedantry, but I have ready at hand a very short and basic
> c++ testcode (reduced from the Haney tests) which today is 2 times (!) slower
> than one week ago on i686 (-O2)... Do you have time to look a little bit at
> it? Here it is (PR4714 for some more details):
Sure!
I will try to figure out what has changed.

Thanks a lot for nice testcase.  I need to read gcc-bugs more curefully.
Honza

Why alias set 0 ? (Was: Long term code compactness regression)

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> > > I checked this morning, with last week's gcc-3.1 snapshot.  A few cases
> > > with g77 have slowed down in recent weeks.  The worst examples of
> > In what testcases g77 slowed down recently?
> >
> > Honza
> 
> Jan, sorry for my pedantry, but I have ready at hand a very short and basic
> c++ testcode (reduced from the Haney tests) which today is 2 times (!) slower
> than one week ago on i686 (-O2)... Do you have time to look a little bit at
> it? Here it is (PR4714 for some more details):
Hi,
I am just looking at the attached 
testcase and first thing that looks odd to me is that there
are memory references of alias set zero to the 'n' field of RealMatrix structure:

(insn 239 232 240 (set (reg:SI 113)
        (mem/s/j:SI (plus:SI (reg/v/u/f:SI 58)
                (const_int 4 [0x4])) [0 S4 A32])) -1 (nil)
    (nil))

These appears to get aliased with:

(insn 297 295 299 (set (mem:SF (plus:SI (reg:SI 119)
                (const_int -4 [0xfffffffc])) [2 S4 A32])
        (reg:SF 133)) -1 (nil)
    (nil))

storing result of the multiplication effectivly disallowing any memory hoisting
and strength reduction of array indexing, as the value still needs to be multiplied.

2.95 version appears to have similar problem, but why?

Richard, do you have any idea?

Honza
> 
> ///////////////////////////////////////////////
> class RealMatrix {
> public:
> 
>   float &index(int i, int j)
>     {
>       return d[i - 1 + n[0] * (j - 1)];
>     }
>   float index(int i, int j) const
>     {
>       return d[i - 1 + n[0] * (j - 1)];
>     }
> 
>   int dim(int i) const { return n[i - 1]; }
> 
> private:
> 
>   float *d;
>   int n[4];
> };
> 
> void rmatMul(RealMatrix &t, const RealMatrix &a, const RealMatrix &b)
> {
>   const int M = a.dim(1), N = b.dim(2), K = b.dim(1);
> 
>   for (int j = 1; j <= N; j++)
>     {
>       for (int k = 1; k <= K; k++)
>         {
>           float temp = b.index(k, j);
>           if (temp != 0.0)
>             {
>               for (int i = 1; i <= M; i++)
>                 t.index(i, j) += temp * a.index(i, k);
>             }
>         }
>     }
> }
> /////////////////////////////////////////
> 
> Thanks,
> Paolo.

Re: [BusyBox] Re: Long term code compactness regression

[Jan Hubicka]

> > Date: Sun, 28 Oct 2001 19:54:15 +0100
> > From: Paolo Carlini <pcarlini@unitus.it>
> > To: Jan Hubicka <jh@suse.cz>
> > CC: gcc@gcc.gnu.org
> 
> > Jan, sorry for my pedantry, but I have ready at hand a very short
> > and basic c++ testcode (reduced from the Haney tests) which today is
> > 2 times (!) slower than one week ago on i686 (-O2)... Do you have
> > time to look a little bit at it? Here it is (PR4714 for some more
> > details):
> 
> Have you binary searched the changes and identified the change that
> blew performance?  If not, that would be a big help in identifying
> what went wrong.  If you have, it helps to name the patch that blew
> performance in this type of email.
The slowdown appears to come from the fact that Richard Kenner has fixed
a bug that caused alias code to be bit more aggresive than it can be.

Honza

Re: [BusyBox] Re: Long term code compactness regression

[mike stump]

> Date: Sun, 28 Oct 2001 19:54:15 +0100
> From: Paolo Carlini <pcarlini@unitus.it>
> To: Jan Hubicka <jh@suse.cz>
> CC: gcc@gcc.gnu.org

> Jan, sorry for my pedantry, but I have ready at hand a very short
> and basic c++ testcode (reduced from the Haney tests) which today is
> 2 times (!) slower than one week ago on i686 (-O2)... Do you have
> time to look a little bit at it? Here it is (PR4714 for some more
> details):

Have you binary searched the changes and identified the change that
blew performance?  If not, that would be a big help in identifying
what went wrong.  If you have, it helps to name the patch that blew
performance in this type of email.