[Bug rtl-optimization/28481] New: regression from 3.x: 4.1.1 uses memory where it can use registers

[Bug rtl-optimization/28481] New: regression from 3.x: 4.1.1 uses memory where it can use registers

[vda dot linux at googlemail dot com]

The attached test program uses 5 local variables and this fits into i386
available registers. gcc 3.4.3 manages to do it with -O3.

gcc-4.1.1 -O2 and -O3 are identical and both are worse than gcc-3.4.3 -O3:

# wc -l *.s
  1498 serpent343-O2.s
  1252 serpent343-O3.s <- gcc 3.4.3 is smaller!
  1313 serpent411-O2.s
  1313 serpent411-O3.s

gcc-4.1.1 -Os is better than -O3, but still a tiny bit worse than gcc-3.4.3:

# wc -l serpent343-O3.s serpent411-Os.s
 1252 serpent343-O3.s
 1275 serpent411-Os.s

# size serpent343-O3.o serpent411-Os.o
   3262       0       0    3262     cbe serpent343-O3.o
   3347       0       0    3347     d13 serpent411-Os.o

Additional ingo is in the testcase itself.

(btw does it make sense to include this into testsuite?)


-- 
           Summary: regression from 3.x: 4.1.1 uses memory where it can use
                    registers
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vda dot linux at googlemail dot com
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug rtl-optimization/28481] regression from 3.x: 4.1.1 uses memory where it can use registers

[vda dot linux at googlemail dot com]

------- Comment #1 from vda dot linux at googlemail dot com  2006-07-25 14:45 -------
Created an attachment (id=11934)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11934&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] regression from 3.x: 4.1.1 uses memory where it can use registers

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2006-07-25 15:47 -------
I get

rguenther@alwazn:/tmp> /space/rguenther/install/gcc-3.4.6/bin/gcc -O3 -c
serpent.c 
rguenther@alwazn:/tmp> size serpent.o 
   text    data     bss     dec     hex filename
   3562       0       0    3562     dea serpent.o
rguenther@alwazn:/tmp> /space/rguenther/install/gcc-4.1.1/bin/gcc -O3 -c
serpent.c 
rguenther@alwazn:/tmp> size serpent.o 
   text    data     bss     dec     hex filename
   4137       0       0    4137    1029 serpent.o
rguenther@alwazn:/tmp> /space/rguenther/install/gcc-4.1.1/bin/gcc -O3 -c
serpent.c  -fomit-frame-pointer
rguenther@alwazn:/tmp> size serpent.o 
   text    data     bss     dec     hex filename
   3695       0       0    3695     e6f serpent.o
rguenther@alwazn:/tmp> /space/rguenther/install/gcc-3.4.6/bin/gcc -O3 -c
serpent.c -fomit-frame-pointer
rguenther@alwazn:/tmp> size serpent.o 
   text    data     bss     dec     hex filename
   3526       0       0    3526     dc6 serpent.o

so, confirmed for -O3, but -O3 is about speed - how's that comparing?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] regression from 3.x: 4.1.1 uses memory where it can use registers

[vda dot linux at googlemail dot com]

------- Comment #3 from vda dot linux at googlemail dot com  2006-07-25 17:18 -------
With this test program:

#include <sys/time.h>
#include <stdio.h>
typedef unsigned u32;
struct serpent_ctx { u32 expkey[132]; };
void serpent_encrypt(void *ctx, u32 *dst, const u32 *src);
u32 v[4],u[4];
struct serpent_ctx ctx;
int main() {
        time_t t;
        int count;
        t = time(NULL);
        while(t == time(NULL)) /*wait*/;
        t = time(NULL); count = 0;
        while(t == time(NULL)) {
                serpent_encrypt(&ctx, u, v);
                serpent_encrypt(&ctx, u, v);
                serpent_encrypt(&ctx, u, v);
                serpent_encrypt(&ctx, u, v);
                count++;
        }
        printf("ops/second=%d\n", count);
        return 0;
}

I see that bigger code = slower code:

# size serpent343-O3 serpent411-O3 serpent343-Os
   text    data     bss     dec     hex filename
   4285     260     592    5137    1411 serpent343-O3
   4461     260     592    5313    14c1 serpent411-O3
   5101     260     592    5953    1741 serpent343-Os

343-O3 is just tiny bit smaller, and it also is tiny bit faster:

# ./serpent343-O3;./serpent343-O3;./serpent343-O3;
ops/second=168637
ops/second=166610
ops/second=169509
# ./serpent411-O3;./serpent411-O3;./serpent411-O3;
ops/second=164809
ops/second=163172
ops/second=161431

I tried longer runs. It is definitely not just a test variability.

The biggest is the slowest:

# ./serpent343-Os;./serpent343-Os;./serpent343-Os;
ops/second=158495
ops/second=151342
ops/second=154777

So, yes, this is also a smallish speed regression too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] regression from 3.x: 4.1.1 uses memory where it can use registers

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] regression from 3.x: 4.1.1 uses memory where it can use registers

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] regression from 3.x: 4.1.1 uses memory where it can use registers

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.2                       |4.1.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] regression from 3.x: 4.1.1 uses memory where it can use registers

[vda dot linux at googlemail dot com]

------- Comment #4 from vda dot linux at googlemail dot com  2007-07-22 00:02 -------
With t.c being a timing program from comment #3 and serpent.c from attachment,
I build testing program for 3.4.3, 3.4.6 and 4.2.1, -Os and -O3, like this:

ver=NNN
gcc -Os -o serpent-${ver}-Os serpent.c t.c
gcc -Os -o serpent-${ver}-Os.o -c serpent.c
gcc -O3 -o serpent-${ver}-O3 serpent.c t.c
gcc -O3 -o serpent-${ver}-O3.o -c serpent.c

Performance regression on -O3 (runs at 2/3 speed of 3.4.x). Did four runs of
each:

343-O3
ops/second=712888
ops/second=722059
ops/second=718909
ops/second=713506
346-O3
ops/second=643833
ops/second=712619
ops/second=721724
ops/second=719445
421-O3
ops/second=495349
ops/second=496887
ops/second=490650
ops/second=494522

Size: improved relative to 3.4.x:

# size *-Os.o
   text    data     bss     dec     hex filename
   4302       0       0    4302    10ce serpent-343-Os.o
   4335       0       0    4335    10ef serpent-346-Os.o
   3877       0       0    3877     f25 serpent-421-Os.o

...but 3.4.x was even smaller at -O3 than 4.2.1 at -Os:

# size *-O3.o
   text    data     bss     dec     hex filename
   3292       0       0    3292     cdc serpent-343-O3.o
   3292       0       0    3292     cdc serpent-346-O3.o
   3877       0       0    3877     f25 serpent-421-O3.o

Actually, 4.2.1 seems to generate same code for -Os/-O2/-O3:

# size *421*.o
   text    data     bss     dec     hex filename
   3877       0       0    3877     f25 serpent-421-O2.o
   3877       0       0    3877     f25 serpent-421-O3.o
   3877       0       0    3877     f25 serpent-421-Os.o


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] regression from 3.x: 4.1.1 uses memory where it can use registers

[vda dot linux at googlemail dot com]

------- Comment #5 from vda dot linux at googlemail dot com  2007-07-22 00:10 -------
Basically, the reason for the regression is that 4.2.1 doesn't figure out how
to use i386 registers efficiently. 3.4.3 was able to do it. Difference in
assembly:

# grep 'mov.*(' serpent-343-O3.s | wc -l
21
serpent_encrypt:
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %edi
        pushl   %esi
        pushl   %ebx
        pushl   %edx
        movl    8(%ebp), %edi
        movl    16(%ebp), %ecx
        movl    12(%edi), %eax
....

# grep 'mov.*(' serpent-421-O3.s | wc -l
115    <========= many more moves to memory (to stack actually)
serpent_encrypt:
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %edi
        pushl   %esi
        pushl   %ebx
        subl    $120, %esp <==== allocated storage for spills
        movl    16(%ebp), %eax
        movl    8(%ebp), %edx
        movl    %edx, -128(%ebp)
.....


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] [4.2/4.3/4.4 Regression] regression from 3.x: 4.1.1 uses memory where it can use registers

[jsm28 at gcc dot gnu dot org]

------- Comment #6 from jsm28 at gcc dot gnu dot org  2008-07-04 19:37 -------
Closing 4.1 branch.  (Could do with verification that issue is still present
with 4.3 and trunk.)


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|regression from 3.x: 4.1.1  |[4.2/4.3/4.4 Regression]
                   |uses memory where it can use|regression from 3.x: 4.1.1
                   |registers                   |uses memory where it can use
                   |                            |registers
   Target Milestone|4.1.3                       |4.2.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] [4.2/4.3/4.4 Regression] regression from 3.x: 4.1.1 uses memory where it can use registers

[vda dot linux at googlemail dot com]

------- Comment #7 from vda dot linux at googlemail dot com  2008-07-04 20:33 -------
4.3.1 have number of memory references down from 115 (4.2.1 had that) but still
can't regain the result of 3.4.3 (21 memory reference). Here is how I checked
this:

# i486-linux-uclibc-gcc -v
...
gcc version 4.3.1 (GCC)
# i486-linux-uclibc-gcc -S -fomit-frame-pointer serpent.c -Os -o
serpent-431-Os.s
# i486-linux-uclibc-gcc -S -fomit-frame-pointer serpent.c -O2 -o
serpent-431-O2.s
# i486-linux-uclibc-gcc -S -fomit-frame-pointer serpent.c -O3 -o
serpent-431-O3.s
# grep 'mov.*(' serpent-431-Os.s | wc -l
48
# grep 'mov.*(' serpent-431-O2.s | wc -l
48
# grep 'mov.*(' serpent-431-O3.s | wc -l
48


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] [4.2/4.3/4.4 Regression] regression from 3.x: 4.1.1 uses memory where it can use registers

[vda dot linux at googlemail dot com]

------- Comment #8 from vda dot linux at googlemail dot com  2008-07-04 20:38 -------
Created an attachment (id=15856)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15856&action=view)
result of "gcc-3.4.6 -fomit-frame-pointer serpent.c -O3 -S"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] [4.2/4.3/4.4 Regression] regression from 3.x: 4.1.1 uses memory where it can use registers

[vda dot linux at googlemail dot com]

------- Comment #9 from vda dot linux at googlemail dot com  2008-07-04 20:48 -------
The above comment meant to say "4.3.1 have number of memory references down
from 115 _to 48_.

I also attached the best result so far - gcc-3.4.6 with -O3 genarates assembly
with smallest number of memory references. Here is more correct method of
counting them (counting not only moves, but any memory references (XOR insns),
but not counting LEA instructions which aren't memory references):

# grep '(' serpent-346-O3.s | grep -v lea | wc -l
144
# grep '(' serpent-431-O3.s | grep -v lea | wc -l
186

Another way to see that 3.4.6 -O3 is optimal is to notice the lack of "subl
$NUM, %esp" in prologue (because gcc figured out it does not need to spill any
registers):

serpent_encrypt:
        pushl   %ebp
        pushl   %edi
        pushl   %esi
        pushl   %ebx
        movl    20(%esp), %ebp
        movl    28(%esp), %ecx
        movl    12(%ebp), %edi
        xorl    12(%ecx), %edi
...

4.3.1 looks like this:

serpent_encrypt:
        pushl   %ebp
        pushl   %edi
        pushl   %esi
        pushl   %ebx
        subl    $20, %esp
        movl    48(%esp), %eax
        movl    (%eax), %ecx
        movl    4(%eax), %edx
        movl    8(%eax), %esi
...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] [4.2/4.3/4.4 Regression] regression from 3.x: 4.1.1 uses memory where it can use registers

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2008-09-20 15:06 -------
Trunk does very unfunny things to this testcase as well.  -fno-tree-reassoc
recovers the register allocation problems.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at redhat dot com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |missed-optimization, ra
   Last reconfirmed|0000-00-00 00:00:00         |2008-09-20 15:06:05
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] [4.2/4.3/4.4 Regression] uses memory where it can use registers

[bonzini at gnu dot org]

------- Comment #11 from bonzini at gnu dot org  2009-02-04 11:24 -------
Reconfirmed:

$ ./xgcc -B. serpent.c -O2 -S -o -| wc -l                     => 1380
$ ./xgcc -B. serpent.c -fno-tree-reassoc -O2 -S -o -| wc -l   => 1304


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2008-09-20 15:06:05         |2009-02-04 11:24:49
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] [4.3/4.4/4.5 Regression] uses memory where it can use registers

[jsm28 at gcc dot gnu dot org]

------- Comment #12 from jsm28 at gcc dot gnu dot org  2009-03-31 19:40 -------
Closing 4.2 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.2/4.3/4.4/4.5 Regression]|[4.3/4.4/4.5 Regression]
                   |uses memory where it can use|uses memory where it can use
                   |registers                   |registers
   Target Milestone|4.2.5                       |4.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] [4.3/4.4/4.5 Regression] uses memory where it can use registers

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2009-08-04 12:27 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481

[Bug target/28481] [4.3/4.4/4.5 Regression] uses memory where it can use registers

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2009-09-20 20:20 -------
(In reply to comment #10)
> Trunk does very unfunny things to this testcase as well.  -fno-tree-reassoc
> recovers the register allocation problems.
> 

Then this is a duplication of bug 27855.

*** This bug has been marked as a duplicate of 27855 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481