[Bug regression/26290] New: [4.1 Regression]: some loop optimizations no longer run at -O2

[Bug regression/26290] New: [4.1 Regression]: some loop optimizations no longer run at -O2

[t dot artem at mailcity dot com]

In this simple testcase (file will be attached)

1) GCC 4.1 with -O2 produces code which runs two time slower than with -O3 thus
some optimizations are missing at -O2 because GCC 4.0.2 -O2 works OK and
produces results on par with -O3.

2) GCC 4.1 produces slightly slower code with -O3 than GCC 4.0.2 (with -O3).

P.S. -fregmove was used as an extra compiler flag.


-- 
           Summary: [4.1 Regression]: some loop optimizations no longer run
                    at -O2
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: regression
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: t dot artem at mailcity dot com
 GCC build triplet: i686-pc-linux-gnu-gcc
  GCC host triplet: i686-pc-linux-gnu-gcc
GCC target triplet: i686-pc-linux-gnu-gcc


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

[Bug regression/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[t dot artem at mailcity dot com]

------- Comment #1 from t dot artem at mailcity dot com  2006-02-14 18:52 -------
Created an attachment (id=10850)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10850&action=view)
A testcase

Here's a testcase.

For those who couldn't understand the point: GCC 4.1.0 -O2 produces the code
which runs two times slower than the code produced by GCC 4.0.2.


-- 


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

[Bug regression/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2006-02-15 10:58 -------
Confirmed.  This are the two inner loops:

4.0.2:

.L6:
        movl    -4(%esi), %ecx
        movl    (%edx), %eax
        cmpl    %eax, %ecx
        jle     .L7
        movl    %eax, -4(%esi)
        movl    %ecx, (%edx)
.L7:
        incl    %ebx
        addl    $4, %edx
        cmpl    %edi, %ebx
        jne     .L6


4.1.0:

.L6:
        movl    8(%ebp), %ebx
        movl    4(%edx), %ecx
        movl    -4(%ebx,%eax,4), %ebx
        movl    %ecx, -20(%ebp)
        cmpl    %ecx, %ebx
        movl    %ebx, -16(%ebp)
        jle     .L7
        movl    8(%ebp), %ebx
        movl    %ecx, -4(%ebx,%eax,4)
        movl    -16(%ebp), %ecx
        movl    %ecx, 4(%edx)
.L7:
        incl    -24(%ebp)
        addl    $4, %edx
        cmpl    -24(%ebp), %esi
        jle     .L12
        jmp     .L6

Optimized tree-dumps have for 4.0.2:

<L1>:;
  D.2291 = *((int *) ivtmp.31 + -4B);
  D.2339 = (int *) ivtmp.22;
  D.2296 = *D.2339;
  if (D.2291 > D.2296) goto <L2>; else goto <L3>;

<L2>:;
  *((int *) ivtmp.31 + -4B) = D.2296;
  *D.2339 = D.2291; 

<L3>:;
  ivtmp.19 = ivtmp.19 + 1;
  ivtmp.22 = ivtmp.22 + 4B;
  if (ivtmp.19 != (unsigned int) cnt - (unsigned int) j) goto <L1>; else goto
<L8>;

and for 4.1.0:

<L1>:;
  D.2434 = MEM[base: lst, index: D.2540, step: 4B, offset: -4B];
  D.2534 = (int *) ivtmp.49;
  D.2439 = MEM[base: D.2534, offset: 4B];
  if (D.2434 > D.2439) goto <L2>; else goto <L3>;

<L2>:;
  MEM[base: lst, index: D.2540, step: 4B, offset: -4B] = D.2439;
  MEM[base: D.2534, offset: 4B] = D.2434;

<L3>:; 
  j.56 = j.56 + 1;
  ivtmp.49 = ivtmp.49 + 4B;
  if (cnt > j.56) goto <L1>; else goto <L8>;

which doesn't look too much worse.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-02-15 10:58:11
               date|                            |


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

[Bug regression/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2006-02-15 11:19 -------
mainline is sane again:

.L6:
        movl    -4(%edx), %esi
        movl    %esi, -20(%ebp)
        movl    (%ecx), %esi
        cmpl    %esi, -20(%ebp)
        jle     .L7
        movl    %esi, -4(%edx)
        movl    -20(%ebp), %esi
        movl    %esi, (%ecx)
.L7:
        addl    $1, %ebx
        addl    $4, %ecx
        cmpl    %ebx, %edi
        jle     .L4
        jmp     .L6

though notice the
        jle     .L4
        jmp     .L6
jumps - a jgt .L6 would probably be more branch unit friendly.  But I think
we have a separate bug for this already.

Maybe Zdenek can investigate?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rakdver at gcc dot gnu dot
                   |                            |org


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

[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |minor
          Component|regression                  |target
           Keywords|                            |missed-optimization
   Target Milestone|---                         |4.1.0


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

[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[t dot artem at mailcity dot com]

-- 

t dot artem at mailcity dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |major


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

[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[mmitchel at gcc dot gnu dot org]

------- Comment #4 from mmitchel at gcc dot gnu dot org  2006-02-18 06:43 -------
Not a showstopper, but definitely disappointing.  I'd be very interested in
analysis of what's going wrong.


-- 

mmitchel at gcc dot gnu dot org changed:

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


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

[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[steven at gcc dot gnu dot org]

------- Comment #5 from steven at gcc dot gnu dot org  2006-02-18 14:32 -------
For the record, AMD64  (usr-)timings:

GCC 4.0         GCC 4.1
0m5.412s        0m4.400s
0m5.388s        0m4.404s
0m5.408s        0m4.404s

So for AMD64 we in fact booked significant progress in GCC 4.1 wrt. GCC 4.0.

This is with:
xgcc (GCC) 4.0.3 20060211 (prerelease)
xgcc (GCC) 4.1.0 20060211 (prerelease)


-- 


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

[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[steven at gcc dot gnu dot org]

------- Comment #6 from steven at gcc dot gnu dot org  2006-02-18 14:36 -------
Timings with the same compilers on the same machine, but with -m32
-march=pentium4 (but still with -O2):

GCC 4.0         GCC 4.1
0m4.148s        0m8.817s
0m4.140s        0m8.785s
0m4.164s        0m8.761s

So:
1) We produce _faster_ code with GCC 4.0 -m32 than with -m64
2) GCC 4.1 -m32 produces code that is twice as slow as GCC 4.0 -m32, as
reported.

Both points are odd (and no, I did not by accident swap the results somwhere
;-)


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2006-02-15 10:58:11         |2006-02-18 14:36:15
               date|                            |


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

[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[steven at gcc dot gnu dot org]

------- Comment #8 from steven at gcc dot gnu dot org  2006-02-18 14:39 -------
Loop body with GCC 4.0:

<L0>:;
  j = i + 1;
  if (cnt > j) goto <L12>; else goto <L8>;

<L12>:;
  ivtmp.22 = (int *) ivtmp.31;
  ivtmp.19 = 0;

<L1>:;
  D.2609 = *((int *) ivtmp.31 + 4294967292B);
  D.2657 = (int *) ivtmp.22;
  D.2614 = *D.2657;
  if (D.2609 > D.2614) goto <L2>; else goto <L3>;

<L2>:;
  *((int *) ivtmp.31 + 4294967292B) = D.2614;
  *D.2657 = D.2609;

<L3>:;
  ivtmp.19 = ivtmp.19 + 1;
  ivtmp.22 = ivtmp.22 + 4B;
  if (ivtmp.19 != (unsigned int) cnt - (unsigned int) j) goto <L1>; else goto
<L8>;

<L8>:;
  ivtmp.31 = ivtmp.31 + 4B;
  i = j;

<L6>:;
  if (i < pretmp.14) goto <L0>; else goto <L7>;


-- 


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

[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[steven at gcc dot gnu dot org]

------- Comment #7 from steven at gcc dot gnu dot org  2006-02-18 14:39 -------
Loop body with GCC 4.1:
<L0>:;
  j = i + 1;
  if (cnt > j) goto <L12>; else goto <L8>;

<L12>:;
  ivtmp.49 = (int *) ivtmp.54;
  j.56 = j;

<L1>:;
  D.2857 = (int *) j;
  D.2751 = MEM[base: lst, index: D.2857, step: 4B, offset: 4294967292B];
  D.2851 = (int *) ivtmp.49;
  D.2756 = MEM[base: D.2851, offset: 4B];
  if (D.2751 > D.2756) goto <L2>; else goto <L3>;

<L2>:;
  MEM[base: lst, index: D.2857, step: 4B, offset: 4294967292B] = D.2756;
  MEM[base: D.2851, offset: 4B] = D.2751;

<L3>:;
  j.56 = j.56 + 1;
  ivtmp.49 = ivtmp.49 + 4B;
  if (cnt > j.56) goto <L1>; else goto <L8>;

<L8>:;
  ivtmp.54 = ivtmp.54 + 4B;
  i = j;

<L6>:;
  if (i < pretmp.39) goto <L0>; else goto <L7>;


-- 


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

[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[steven at gcc dot gnu dot org]

------- Comment #9 from steven at gcc dot gnu dot org  2006-02-19 09:13 -------
I have no idea yet what's happening here, but I'm going to find out...


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-02-18 14:36:15         |2006-02-19 09:13:57
               date|                            |


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

[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[steven at gcc dot gnu dot org]

------- Comment #10 from steven at gcc dot gnu dot org  2006-02-19 13:41 -------
I modified the test case a bit to make it easier to understand what is going
on:

void
do_sort (int *lst, int cnt)
{
  int i, j, k;
  for (i = 0; i < cnt - 1; i++)
    {
      for (j = i + 1; j < cnt; j++)
        {
          int lsti = lst[i];
          int lstj = lst[j];

          if (lsti > lstj)
            {
              lst[i] = lstj;
              lst[j] = lsti;
            }
        }
    }
}

This gives two very different inner loops:

GCC 4.0:
.L6:
        movl    -4(%esi), %ecx
        movl    (%edx), %eax
        cmpl    %eax, %ecx
        jle     .L7
        movl    %eax, -4(%esi)
        movl    %ecx, (%edx)
.L7:
        addl    $1, %ebx
        addl    $4, %edx
        cmpl    %edi, %ebx
        jne     .L6

GCC 4.1:
.L6:
        movl    8(%ebp), %ebx
        movl    -4(%ebx,%eax,4), %ebx
        movl    %ebx, -20(%ebp)
        movl    4(%ecx), %esi
        movl    %esi, -24(%ebp)
        cmpl    %esi, %ebx
        jle     .L7
        movl    8(%ebp), %ebx
        movl    %esi, -4(%ebx,%eax,4)
        movl    -20(%ebp), %esi
        movl    %esi, 4(%ecx)
.L7:
        addl    $1, -28(%ebp)
        addl    $4, %ecx
        cmpl    -28(%ebp), %edi
        jg      .L6

So there are two problems:
- The addressing modes are different.  This is due to the TARGET_MEM_REF
  stuff that Zdenek added.
- We need at least one register more apparently, judging from the extra
  stack moves.


Interestingly, if I change the test case to:
void
do_sort (int *lst, int cnt)
{
  int i, j, k;
  for (i = 0; i < cnt - 1; i++)
    {
      for (j = 0/*i + 1*/; j < cnt; j++)
        {
          int lsti = lst[i];
          int lstj = lst[j];

          if (lsti > lstj)
            {
              lst[i] = lstj;
              lst[j] = lsti;
            }
        }
    }
}

then the code produced by GCC 4.1 is 20% faster than what GCC 4.0 makes of it.

Zdenek, this really looks like one for you...


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug target/26290] [4.1 Regression]: some loop optimizations no longer run at -O2

[steven at gcc dot gnu dot org]

------- Comment #11 from steven at gcc dot gnu dot org  2006-02-19 13:42 -------
At least related to register allocation.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ra


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

[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[t dot artem at mailcity dot com]

------- Comment #12 from t dot artem at mailcity dot com  2006-02-21 04:56 -------
This bug may affect real applications performance so I believe it's worth being
resolved for 4.1.0 release. What if one changes severity to critical though
certanly this bug isn't critical?


-- 


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

[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[mmitchel at gcc dot gnu dot org]

------- Comment #13 from mmitchel at gcc dot gnu dot org  2006-02-24 00:27 -------
This issue will not be resolved in GCC 4.1.0; retargeted at GCC 4.1.1.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.0                       |4.1.1


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

[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[rakdver at gcc dot gnu dot org]

------- Comment #14 from rakdver at gcc dot gnu dot org  2006-02-24 15:20 -------
Ivopts fail to use the complex addressing mode, thus forcing one more biv into
inner loop.  Since this makes it impossible to allocate registers for the loop,
we  get another penalty for spilling.

Changing the initial value makes us notice that we may perform IV elimination,
thus getting rid of the extra register.


-- 

rakdver at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-02-19 09:13:57         |2006-02-24 15:20:29
               date|                            |


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

[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[mmitchel at gcc dot gnu dot org]

------- Comment #15 from mmitchel at gcc dot gnu dot org  2006-05-25 02:34 -------
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.


-- 

mmitchel at gcc dot gnu dot org changed:

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


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

[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[t dot artem at mailcity dot com]

------- Comment #16 from t dot artem at mailcity dot com  2007-02-02 17:02 -------
Since GCC 4.1.2 RC1 is already out, does that mean that this bug is postponed
till GCC 4.1.3/4.2.0?


-- 


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

[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[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=26290

[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[opruz at centrum dot cz]

------- Comment #17 from opruz at centrum dot cz  2007-04-19 17:29 -------
4.1.2 -m32 -O2

.L6:
        movl    8(%ebp), %ebx
        movl    4(%edx), %ecx
        movl    -4(%ebx,%eax,4), %ebx
        movl    %ecx, -20(%ebp)
        cmpl    %ecx, %ebx
        movl    %ebx, -16(%ebp)
        jle     .L7
        movl    8(%ebp), %ebx
        movl    %ecx, -4(%ebx,%eax,4)
        movl    -16(%ebp), %ecx
        movl    %ecx, 4(%edx)
.L7:
        incl    -24(%ebp)
        addl    $4, %edx
        cmpl    -24(%ebp), %esi
        jle     .L12
        jmp     .L6

4.1.2 -m32 -O2

.L6:
        movl    -4(%rdx), %r10d
        movl    (%rcx), %r8d
        cmpl    %r8d, %r10d
        jle     .L7
        movl    %r8d, -4(%rdx)
        movl    %r10d, (%rcx)
.L7:
        incl    %edi
        addq    $4, %rcx
        cmpl    %edi, %esi
        jle     .L4
        jmp     .L6

Looks like noone gives a shit though...


-- 


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

[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[t dot artem at mailcity dot com]

------- Comment #18 from t dot artem at mailcity dot com  2007-05-18 08:32 -------
As for GCC 4.2.0 the bug is still relevant.


-- 


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

[Bug target/26290] [4.1/4.2/4.3 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[pinskia at gcc dot gnu dot org]

------- Comment #19 from pinskia at gcc dot gnu dot org  2007-07-04 21:32 -------
>  lsti = MEM[index: ivtmp.46, offset: 0x0fffffffffffffffc];

Hmmmm.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ra                          |


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

[Bug target/26290] [4.1/4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2007-11-04 11:45 -------
With mainline we now get

        .p2align 4,,7
        .p2align 3
.L6:
        addl    $1, %eax
        cmpl    %eax, %edi
        movl    %eax, -20(%ebp)
        jle     .L3
        movl    %eax, %ecx
        movl    %esi, %edx
        .p2align 4,,7
        .p2align 3
.L5:
        movl    -4(%esi), %ebx
        movl    (%edx), %eax
        cmpl    %eax, %ebx
        jle     .L4
        movl    %eax, -4(%esi)
        movl    %ebx, (%edx)
.L4:
        addl    $1, %ecx
        addl    $4, %edx
        cmpl    %ecx, %edi
        jg      .L5
.L3:
        movl    -20(%ebp), %eax
        addl    $4, %esi
        cmpl    -16(%ebp), %eax
        jl      .L6

which looks good, apart from the issue Andrew pointed out (but that's
PR26726):

  lsti_11 = MEM[index: ivtmp.27_14, offset: 0x0fffffffc];

  MEM[index: ivtmp.27_14, offset: 0x0fffffffc] = lstj_15;

4.0 is still faster with the original testcase, but the only difference I
can spot is that mainline uses addl $1, %eax while 4.0 uses incl here.  Oh,
and 4.0 uses an extra induction variable(!) for the exit test (and less
loop alignment):

.L3:
        incl    %eax
        cmpl    %eax, 12(%ebp)
        movl    %eax, -20(%ebp)
        jle     .L4
        movl    12(%ebp), %edi
        movl    %esi, %edx
        xorl    %ebx, %ebx
        subl    %eax, %edi
        .p2align 4,,15
.L6:
        movl    -4(%esi), %ecx
        movl    (%edx), %eax
        cmpl    %eax, %ecx
        jle     .L7
        movl    %eax, -4(%esi)
        movl    %ecx, (%edx)
.L7:
        incl    %ebx
        addl    $4, %edx
        cmpl    %edi, %ebx
        jne     .L6
.L4:
        movl    -20(%ebp), %eax
        addl    $4, %esi
        cmpl    -16(%ebp), %eax
        jl      .L3

Using -mtune=core2 on trunk get's back the incl and makes the code faster
than 4.0 (on my Core CPU, that is).  So the generic tuning here makes the
difference for trunk.

4.2 is still broken, though.  I would say let's close this as fixed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|4.0.4                       |4.0.4 4.3.0
   Last reconfirmed|2006-02-24 15:20:29         |2007-11-04 11:45:07
               date|                            |
            Summary|[4.1/4.2/4.3 Regression]:   |[4.1/4.2 Regression]: code
                   |code pessimization wrt. GCC |pessimization wrt. GCC 4.0
                   |4.0 probably due to         |probably due to
                   |TARGET_MEM_REF              |TARGET_MEM_REF


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

[Bug target/26290] [4.1/4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[t dot artem at mailcity dot com]

------- Comment #21 from t dot artem at mailcity dot com  2007-11-04 13:42 -------
> I would say let's close this as fixed.

Do you mean that GCC 4.1 and 4.2 will never have this bug fixed and we have to
wait till 4.3 is out?

Besides, have you tested this bug on architectures other that Intel core2?
Originally this bug affected plain i386 code.


-- 


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

[Bug target/26290] [4.1/4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2007-11-04 14:53 -------
Yes, I looked at i386 and i686 tuned code as well (which gets the addl), the
core2 tuning has this fixed (I didn't measure on AMD CPUs).  As both 4.1 and
4.2 are way into maintainance mode and the patch which fixed this has not
been identified yet this indeed has only minor chances of getting fixed for
4.1 or 4.2.


-- 


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

[Bug target/26290] [4.1/4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[t dot artem at mailcity dot com]

------- Comment #23 from t dot artem at mailcity dot com  2008-03-09 19:03 -------
Since GCC 4.3.0 is out and this bug is no longer reproducible I suppose it's
worth marking this bug as FIXED.

Wow, it took exactly two years to fix this bug :-)


-- 

t dot artem at mailcity dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   GCC host triplet|i686-pc-linux-gnu-gcc       |i686-pc-linux-gnu
      Known to fail|4.2.0                       |4.1.2 4.2.3


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

[Bug target/26290] [4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[jsm28 at gcc dot gnu dot org]

------- Comment #24 from jsm28 at gcc dot gnu dot org  2008-07-04 20:20 -------
Closing 4.1 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2 Regression]: code  |[4.2 Regression]: code
                   |pessimization wrt. GCC 4.0  |pessimization wrt. GCC 4.0
                   |probably due to             |probably due to
                   |TARGET_MEM_REF              |TARGET_MEM_REF
   Target Milestone|4.1.3                       |4.2.5


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

[Bug target/26290] [4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF

[jsm28 at gcc dot gnu dot org]

------- Comment #25 from jsm28 at gcc dot gnu dot org  2009-03-30 15:48 -------
Closing 4.2 branch, fixed in 4.3.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|4.1.2 4.2.3                 |4.1.2 4.2.3 4.2.5
         Resolution|                            |FIXED
   Target Milestone|4.2.5                       |4.3.0


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