[Bug tree-optimization/32183] New: Gcc 4.3 revision 125030 miscompiles 482.sphinx3 in SPEC CPU 2006

[Bug tree-optimization/32183] New: Gcc 4.3 revision 125030 miscompiles 482.sphinx3 in SPEC CPU 2006

[hjl at lucon dot org]

With -O2 -ffast-math on Linux/x86-64, I got

  Running (#1) 482.sphinx3 ref base o2 default
Error with '/export/spec/src/2006/spec/bin/specinvoke -E -d
/export/spec/src/2006/spec/benchspec/CPU2006/482.sphinx3/run/run_base_ref_o2.0000
-c 1 -e compare.err -o compare.stdout -f compare.cmd': check file
'/export/spec/src/2006/spec/benchspec/CPU2006/482.sphinx3/run/run_base_ref_o2.0000/.err'
*** Miscompare of considered.out, see
/export/spec/src/2006/spec/benchspec/CPU2006/482.sphinx3/run/run_base_ref_o2.0000/considered.out.mis
Invalid run; unable to continue.  If you wish to ignore errors please use '-I'
or ignore_errors

You can get sphinx3 from

http://cmusphinx.sourceforge.net/html/download.php#sphinx3

The miscompiled file is cmn_prior.c. The difference in assembly output
between revision 125029 and revision 125030 is

--- revision 125029 cmn_prior.s 2007-06-01 12:15:49.000000000 -0700
+++ revision 125030 cmn_prior.s 2007-06-01 12:16:17.000000000 -0700
@@ -78,21 +78,22 @@ cmn_prior:
        testl   %ebp, %ebp
        movsd   .LC6(%rip), %xmm0
        divsd   %xmm1, %xmm0
-       cvtsd2ss        %xmm0, %xmm1
+       cvtsd2ss        %xmm0, %xmm2
        jle     .L10
        xorl    %eax, %eax
 .L11:
-       movaps  %xmm1, %xmm0
+       movaps  %xmm2, %xmm0
        mulss   (%rcx,%rax,4), %xmm0
        movss   %xmm0, (%rsi,%rax,4)
        addq    $1, %rax
        cmpl    %eax, %ebp
        jg      .L11
-       mulss   .LC7(%rip), %xmm1
        xorl    %eax, %eax
+       movss   .LC7(%rip), %xmm1
 .L12:
        movss   (%rcx,%rax,4), %xmm0
        mulss   %xmm1, %xmm0
+       mulss   %xmm2, %xmm0
        movss   %xmm0, (%rcx,%rax,4)
        addq    $1, %rax
        cmpl    %eax, %ebp
@@ -107,11 +108,11 @@ cmn_prior:
        testl   %ebp, %ebp
        cvtsi2sd        %edx, %xmm1
        divsd   %xmm1, %xmm0
-       cvtsd2ss        %xmm0, %xmm1
+       cvtsd2ss        %xmm0, %xmm2
        jle     .L13
        xorl    %eax, %eax
 .L14:
-       movaps  %xmm1, %xmm0
+       movaps  %xmm2, %xmm0
        mulss   (%rcx,%rax,4), %xmm0
        movss   %xmm0, (%rsi,%rax,4)
        addq    $1, %rax
@@ -122,11 +123,12 @@ cmn_prior:
        jle     .L17
        testl   %ebp, %ebp
        jle     .L15
-       mulss   .LC7(%rip), %xmm1
        xorl    %eax, %eax
+       movss   .LC7(%rip), %xmm1
 .L16:
        movss   (%rcx,%rax,4), %xmm0
        mulss   %xmm1, %xmm0
+       mulss   %xmm2, %xmm0
        movss   %xmm0, (%rcx,%rax,4)
        addq    $1, %rax
        cmpl    %eax, %ebp


-- 
           Summary: Gcc 4.3 revision 125030 miscompiles 482.sphinx3 in SPEC
                    CPU 2006
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl at lucon dot org
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug tree-optimization/32183] Gcc 4.3 revision 125030 miscompiles 482.sphinx3 in SPEC CPU 2006

[hjl at lucon dot org]

------- Comment #1 from hjl at lucon dot org  2007-06-01 22:13 -------
Created an attachment (id=13649)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13649&action=view)
A testcase

This testcase has 2 assembly files compiled with -O2 -ffast-math. good.s is
good and bad.s is bad.


-- 


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

[Bug tree-optimization/32183] Gcc 4.3 revision 125030 miscompiles 482.sphinx3 in SPEC CPU 2006

[hjl at lucon dot org]

------- Comment #2 from hjl at lucon dot org  2007-06-01 23:09 -------
Is that OK to transform

      float sf;
      ...
      sf = 500 * sf;
      for (i = 0; i < ceplen; i++)
        sum[i] *= sf;

to

      for (i = 0; i < ceplen; i++)
        sum[i] = (sum[i]* 500)*sf;

You can certainly get the different results when sf is small and sum[i] is
large.


-- 


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

[Bug tree-optimization/32183] Gcc 4.3 revision 125030 miscompiles 482.sphinx3 in SPEC CPU 2006

[rakdver at gcc dot gnu dot org]

------- Comment #3 from rakdver at gcc dot gnu dot org  2007-06-01 23:13 -------
(In reply to comment #2)
> Is that OK to transform
> 
>       float sf;
>       ...
>       sf = 500 * sf;
>       for (i = 0; i < ceplen; i++)
>         sum[i] *= sf;
> 
> to
> 
>       for (i = 0; i < ceplen; i++)
>         sum[i] = (sum[i]* 500)*sf;
> 
> You can certainly get the different results when sf is small and sum[i] is
> large.

with -ffast-math, this transformation is ok (although it does not seem to make
sense to do it, it moves a multiplication into a loop).


-- 


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

[Bug tree-optimization/32183] -fast-math causes a missed optimization to happen

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-06-02 00:01 -------
So this is not a wrong code, just a missed optimization.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Gcc 4.3 revision 125030     |-fast-math causes a missed
                   |miscompiles 482.sphinx3 in  |optimization to happen
                   |SPEC CPU 2006               |


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

[Bug tree-optimization/32183] -fast-math causes a missed optimization to happen

[hjl at lucon dot org]

------- Comment #5 from hjl at lucon dot org  2007-06-02 00:10 -------
(In reply to comment #3)
> (In reply to comment #2)
> > Is that OK to transform
> > 
> >       float sf;
> >       ...
> >       sf = 500 * sf;
> >       for (i = 0; i < ceplen; i++)
> >         sum[i] *= sf;
> > 
> > to
> > 
> >       for (i = 0; i < ceplen; i++)
> >         sum[i] = (sum[i]* 500)*sf;
> > 
> > You can certainly get the different results when sf is small and sum[i] is
> > large.
> 
> with -ffast-math, this transformation is ok (although it does not seem to make
> sense to do it, it moves a multiplication into a loop).
>

We moved a multiply, which is outside of loop in source, into
a loop. I don't think gcc should do it with any optimization
flag, including -ffast-math.


-- 


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

[Bug tree-optimization/32183] reassoc can more extra calculations into a loop

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2007-06-02 00:21 -------
(In reply to comment #5)
> We moved a multiply, which is outside of loop in source, into
> a loop. I don't think gcc should do it with any optimization
> flag, including -ffast-math.

Yes but this is still just a missed optimization rather than a wrong code
issue.

reassoc2 is not checking if it is going to move stuff in the loop.
--- foo.c.107t.recip    2007-06-01 17:18:04.000000000 -0700
+++ foo.c.108t.reassoc2 2007-06-01 17:18:04.000000000 -0700
@@ -178,15 +178,15 @@ cmn_prior (incep, varnorm, nfr, ceplen,
   goto <bb 8> (<L64>);

 <L102>:;
-  D.1857_156 = nframe_lsm.64_93 + 1;
   D.1858_191 = (unsigned int) nfr_17(D);
   D.1859_190 = D.1858_191 + 0x0ffffffff;
   D.1860_52 = (int32) D.1859_190;
+  D.1857_156 = nframe_lsm.64_93 + 1;
   nframe_lsm.64_35 = D.1857_156 + D.1860_52;
-  D.1861_38 = nframe_lsm.64_93 + 1;
   D.1862_37 = (unsigned int) nfr_17(D);
   D.1863_155 = D.1862_37 + 0x0ffffffff;
   D.1864_6 = (int) D.1863_155;
+  D.1861_38 = nframe_lsm.64_93 + 1;
   nframe.8_36 = D.1861_38 + D.1864_6;
   # nframe_73 = VDEF <nframe_134>
   nframe = nframe_lsm.64_35;
@@ -217,7 +217,7 @@ cmn_prior (incep, varnorm, nfr, ceplen,
   D.1890_104 = (unsigned int) i_14;
   # VUSE <SMT.14_63>
   D.1709_89 = MEM[base: sum.6_87, index: D.1890_104, step: 4];
-  D.1710_90 = D.1709_89 * sf_77;
+  D.1710_90 = sf_77 * D.1709_89;
   D.1891_102 = (unsigned int) i_14;
   # SMT.14_183 = VDEF <SMT.14_63>
   MEM[base: cur_mean.3_82, index: D.1891_102, step: 4] = D.1710_90;


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dberlin at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |missed-optimization
   Last reconfirmed|0000-00-00 00:00:00         |2007-06-02 00:21:27
               date|                            |
            Summary|-fast-math moves multiply   |reassoc can more extra
                   |into a loop                 |calculations into a loop


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

[Bug tree-optimization/32183] reassoc can more extra calculations into a loop

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2007-06-02 00:24 -------
This happens with integers too.  That is if you do:
s/float float32/int float32/
You still get the diff:
@@ -184,15 +178,15 @@ cmn_prior (incep, varnorm, nfr, ceplen,
   goto <bb 8> (<L64>);

 <L102>:;
-  D.1857_156 = nframe_lsm.64_93 + 1;
   D.1858_191 = (unsigned int) nfr_17(D);
   D.1859_190 = D.1858_191 + 0x0ffffffff;
   D.1860_52 = (int32) D.1859_190;
+  D.1857_156 = nframe_lsm.64_93 + 1;
   nframe_lsm.64_35 = D.1857_156 + D.1860_52;
-  D.1861_38 = nframe_lsm.64_93 + 1;
   D.1862_37 = (unsigned int) nfr_17(D);
   D.1863_155 = D.1862_37 + 0x0ffffffff;
   D.1864_6 = (int) D.1863_155;
+  D.1861_38 = nframe_lsm.64_93 + 1;
   nframe.8_36 = D.1861_38 + D.1864_6;
   # nframe_73 = VDEF <nframe_134>
   nframe = nframe_lsm.64_35;
@@ -223,7 +217,7 @@ cmn_prior (incep, varnorm, nfr, ceplen,
   D.1890_104 = (unsigned int) i_14;
   # VUSE <SMT.14_63>
   D.1709_89 = MEM[base: sum.6_87, index: D.1890_104, step: 4];
-  D.1710_90 = D.1709_89 * sf_77;
+  D.1710_90 = sf_77 * D.1709_89;
   D.1891_102 = (unsigned int) i_14;
   # SMT.14_183 = VDEF <SMT.14_63>
   MEM[base: cur_mean.3_82, index: D.1891_102, step: 4] = D.1710_90;


-- 


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

[Bug tree-optimization/32183] reassoc can more extra calculations into a loop

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2007-06-02 00:26 -------
I pasted the wrong part of the diff:
   # SMT.14_85 = PHI <SMT.14_183(16)>
 <L106>:;
   sum.6_192 = sum.6_87;
-  pretmp.56_197 = sf_77 * 500;

   # SMT.14_64 = PHI <SMT.14_184(18), SMT.14_85(17)>
   # i_74 = PHI <i_107(18), 0(17)>
@@ -244,7 +237,8 @@ cmn_prior (incep, varnorm, nfr, ceplen,
   D.1883_123 = (unsigned int) i_74;
   # VUSE <SMT.14_64>
   D.1709_105 = MEM[base: sum.6_87, index: D.1883_123, step: 4];
-  D.1710_106 = D.1709_105 * pretmp.56_197;
+  pretmp.56_197 = D.1709_105 * 500;
+  D.1710_106 = pretmp.56_197 * sf_77;
   D.1884_118 = (unsigned int) i_74;
   # SMT.14_184 = VDEF <SMT.14_64>
   MEM[base: sum.6_87, index: D.1884_118, step: 4] = D.1710_106;
@@ -293,7 +287,7 @@ cmn_prior (incep, varnorm, nfr, ceplen,


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2007-06-02 00:37 -------
Here is a simple example:
int f(int i, int *k, int l)
{
  int j;
  i*=20;
  for(j= 0 ;j<10;j++)
    k[j] *=i;
}

Where we change the order to be slower by pulling into the loop the multiply by
20.  This is a recent regression too.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|reassoc can more extra      |[4.3 Regression] reassoc2
                   |calculations into a loop    |can more extra calculations
                   |                            |into a loop
   Target Milestone|---                         |4.3.0


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

------- Comment #10 from hjl at lucon dot org  2007-06-02 00:42 -------
(In reply to comment #9)

> 
> Where we change the order to be slower by pulling into the loop the multiply by
> 20.  This is a recent regression too.
> 

I will try to track down which checkin causes this.


-- 

hjl at lucon dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.0                       |---


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.3.0


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2007-06-02 00:56 -------
(In reply to comment #10)
> I will try to track down which checkin causes this.
No need, it was just the addition of DCE.  So what is happening now is that DCE
removes the other use of the multiply so reassiocation can happen and then
reassiocation just happens to make it worse than it was before.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|x86_64-unknown-linux-gnu    |


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2007-06-02 00:58 -------
Maybe someone should timings without the second reassoc.
Jeff mentioned the loop optimizers cause new reassociations:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00469.html
And Daniel Berlin agreed with him (but this was before a DCE was added):
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00473.html


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

------- Comment #13 from hjl at lucon dot org  2007-06-02 02:00 -------
(In reply to comment #11)
> (In reply to comment #10)
> > I will try to track down which checkin causes this.
> No need, it was just the addition of DCE.  So what is happening now is that DCE
> removes the other use of the multiply so reassiocation can happen and then
> reassiocation just happens to make it worse than it was before.
> 

Has anyone measured impact of adding DCE on SPEC CPU 2000/2006 peformance?


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2007-06-02 02:23 -------
(In reply to comment #13)
> Has anyone measured impact of adding DCE on SPEC CPU 2000/2006 peformance?

Take a look at:
http://www.suse.de/~gcctest/SPEC/CFP/sb-haydn-head-64-32o-32bit/172_mgrid_recent_big.png
And:
http://www.suse.de/~gcctest/SPEC/CFP/sb-haydn-head-64-32o-32bit/301_apsi_recent_big.png

You will see two big jumps, those are from the impact of adding the DCE.

Likewise for ia64:
http://www.suse.de/~gcctest/SPEC/CFP/sb-terbium-head-64/172_mgrid_recent_big.png
http://www.suse.de/~gcctest/SPEC/CFP/sb-terbium-head-64/301_apsi_recent_big.png

And amd64:
http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/172_mgrid_recent_big.png
http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/301_apsi_recent_big.png

Thanks,
Andrew Pinski 


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[rakdver at kam dot mff dot cuni dot cz]

------- Comment #15 from rakdver at kam dot mff dot cuni dot cz  2007-06-02 07:49 -------
Subject: Re:  [4.3 Regression] reassoc2 can more extra calculations into a loop

> > Has anyone measured impact of adding DCE on SPEC CPU 2000/2006 peformance?
> 
> Take a look at:
> http://www.suse.de/~gcctest/SPEC/CFP/sb-haydn-head-64-32o-32bit/172_mgrid_recent_big.png

actually, the mgrid jump is due to predictive commoning.


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

------- Comment #16 from hjl at lucon dot org  2007-06-02 14:20 -------
Here are SPEC CPU 2K -O2 -ffast-math differences between revision
125029 and revision 125029 on Intel64 C2D:

                          (r125030 - r125029)/r125029
164.gzip                         0.0706714%
175.vpr                          -0.116077%
176.gcc                          -1.83805%
181.mcf                          0.968263%
186.crafty                       0.351975%
197.parser                       -0.15456%
252.eon                          -0.324675%
253.perlbmk                      -0.0394945%
254.gap                          -0.318471%
255.vortex                       0.211775%
256.bzip2                        0.300601%
300.twolf                        0%
Est. SPECint_base2000            -0.0983284%

168.wupwise                      0.92511%
171.swim                         -0.0767165%
172.mgrid                        0.179856%
173.applu                        -3.62731%
177.mesa                         0.0398565%
178.galgel                       -4.55329%
179.art                          -1.38686%
183.equake                       0.303819%
187.facerec                      -0.383583%
188.ammp                         -0.7768%
189.lucas                        -1.30465%
191.fma3d                        1.38667%
200.sixtrack                     -0.135318%
301.apsi                         0.0545256%
Est. SPECfp_base2000             -0.660502%

Here are SPEC CPU 2K -O2 -ffast-math differences between revision
125029 with DCE change disabled and revision 125029 on Intel64:

                          (r125030 no DCE - r125029)/r125029

164.gzip                         0.0706714%
175.vpr                          0%
176.gcc                          0%
181.mcf                          0.484131%
186.crafty                       0.195542%
197.parser                       -0.15456%
252.eon                          -0.202922%
253.perlbmk                      0.35545%
254.gap                          0.181984%
255.vortex                       0.16942%
256.bzip2                        -0.150301%
300.twolf                        0.0389257%
Est. SPECint_base2000            0.0983284%

168.wupwise                      0.264317%
171.swim                         -0.0383583%
172.mgrid                        0%
173.applu                        0.0711238%
177.mesa                         0%
178.galgel                       0.123062%
179.art                          -3.16302%
183.equake                       0.0434028%
187.facerec                      -0.115075%
188.ammp                         0.0517866%
189.lucas                        0.0705219%
191.fma3d                        0%
200.sixtrack                     -0.135318%
301.apsi                         0.163577%
Est. SPECfp_base2000             -0.176134%

Given the impact of DCE change, it isn't a real surprise. It not only may not
optimize loop, but may make a loop to run slow. I will bet you will find the
similar results on other architectures.


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

------- Comment #17 from hjl at lucon dot org  2007-06-03 22:41 -------
I am not sure it is a reassoc2 problem since reassoc1 does the same thing and
pre "corrects" it. However pre isn't run after reassoc2 so that the issue
created
by reassoc2 isn't "corrected". Is that possible to run pre again after
reassoc2?


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

------- Comment #18 from hjl at lucon dot org  2007-06-04 21:14 -------
(In reply to comment #12)
> Maybe someone should timings without the second reassoc.
> Jeff mentioned the loop optimizers cause new reassociations:
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00469.html
> And Daniel Berlin agreed with him (but this was before a DCE was added):
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00473.html
>

Here are SPEC CPU 2K -O2 -ffast-math differences between revision
125030 without the second reassoc and revision 125029 on Intel64:

                          (r125030 w/o reassoc2 - r125029)/r125029

164.gzip                         -0.282686%
175.vpr                          -0.928613%
176.gcc                          -0.34774%
181.mcf                          -0.430339%
186.crafty                       0.430192%
197.parser                       -0.231839%
252.eon                          -0.487013%
253.perlbmk                      -0.592417%
254.gap                          0%
255.vortex                       -0.211775%
256.bzip2                        -1.2024%
300.twolf                        0.0389257%
Est. SPECint_base2000            -0.344149%

168.wupwise                      -0.881057%
171.swim                         -0.690449%
172.mgrid                        3.89688%
173.applu                        -4.26743%
177.mesa                         -2.82981%
178.galgel                       -2.04283%
179.art                          -2.65207%
183.equake                       -0.347222%
187.facerec                      0.191791%
188.ammp                         -5.33402%
189.lucas                        1.65726%
191.fma3d                        0.586667%
200.sixtrack                     -0.405954%
301.apsi                         1.47219%
Est. SPECfp_base2000             -0.836636%


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

------- Comment #19 from hjl at lucon dot org  2007-06-04 21:39 -------
Can anyone show that the newly added dce_loop anything useful? Can we disable
it or move it after the second reassoc?


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[rakdver at kam dot mff dot cuni dot cz]

------- Comment #20 from rakdver at kam dot mff dot cuni dot cz  2007-06-04 22:15 -------
Subject: Re:  [4.3 Regression] reassoc2 can more extra calculations into a loop

> Can anyone show that the newly added dce_loop anything useful?

Yes, predictive commoning does not work as well if there is dead code
(which is why it was added.

> Can we disable it or move it after the second reassoc?

Reassoc should be fixed, we should not consider workarounds like this.


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

------- Comment #21 from hjl at lucon dot org  2007-06-04 22:19 -------
(In reply to comment #20)
> Subject: Re:  [4.3 Regression] reassoc2 can more extra calculations into a loop
> 
> > Can anyone show that the newly added dce_loop anything useful?
> 
> Yes, predictive commoning does not work as well if there is dead code
> (which is why it was added.
> 

But predictive commoning isn't enabled at -O2, why add it for -O2? What does
it give us at -O2?


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[rakdver at kam dot mff dot cuni dot cz]

------- Comment #22 from rakdver at kam dot mff dot cuni dot cz  2007-06-04 22:39 -------
Subject: Re:  [4.3 Regression] reassoc2 can more extra calculations into a loop

> > > Can anyone show that the newly added dce_loop anything useful?
> > 
> > Yes, predictive commoning does not work as well if there is dead code
> > (which is why it was added.
> > 
> 
> But predictive commoning isn't enabled at -O2, why add it for -O2? What does
> it give us at -O2?

More precise view of code in loop optimizers.  I cannot give any
concrete example, but in principle this should not be bad and unless
there are some serious reasons against it, I prefer to keep this cleanup
there.


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[rakdver at gcc dot gnu dot org]

-- 

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|2007-06-02 00:21:27         |2007-06-04 22:44:51
               date|                            |


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[dberlin at dberlin dot org]

------- Comment #23 from dberlin at gcc dot gnu dot org  2007-06-04 23:01 -------
Subject: Re:  [4.3 Regression] reassoc2 can more extra calculations into a loop

On 4 Jun 2007 22:15:46 -0000, rakdver at kam dot mff dot cuni dot cz
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #20 from rakdver at kam dot mff dot cuni dot cz  2007-06-04 22:15 -------
> Subject: Re:  [4.3 Regression] reassoc2 can more extra calculations into a loop
>
> > Can anyone show that the newly added dce_loop anything useful?
>
> Yes, predictive commoning does not work as well if there is dead code
> (which is why it was added.
>
> > Can we disable it or move it after the second reassoc?
>
> Reassoc should be fixed, we should not consider workarounds like this.

Either fix or remove reassoc2 works for me :)


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[rakdver at kam dot mff dot cuni dot cz]

------- Comment #24 from rakdver at kam dot mff dot cuni dot cz  2007-06-04 23:23 -------
Subject: Re:  [4.3 Regression] reassoc2 can more extra calculations into a loop

> > > Can anyone show that the newly added dce_loop anything useful?
> >
> > Yes, predictive commoning does not work as well if there is dead code
> > (which is why it was added.
> >
> > > Can we disable it or move it after the second reassoc?
> >
> > Reassoc should be fixed, we should not consider workarounds like this.
> 
> Either fix or remove reassoc2 works for me :)

I suppose there was some reason for having reassoc run twice?


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[rakdver at gcc dot gnu dot org]

------- Comment #25 from rakdver at gcc dot gnu dot org  2007-06-04 23:34 -------
> > Reassoc should be fixed, we should not consider workarounds like this.
> 
> Either fix or remove reassoc2 works for me :)

One possible fix is attached; it prevents us from reassociating across loop
boundaries.  This might be too conservative, though, preventing us from
optimizing e.g. 

x = ...
y = ...

while(...)
  {
    a = ...
    b = a + x;
    while (...)
      c = b + y;
  }

So probably this restriction should be applied only in reassoc2 (or reassoc2
should be removed, if Daniel believes it is not useful).


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[rakdver at gcc dot gnu dot org]

------- Comment #26 from rakdver at gcc dot gnu dot org  2007-06-04 23:35 -------
Created an attachment (id=13656)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13656&action=view)
patch preventing reassociation across loop boundaries


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[dberlin at dberlin dot org]

------- Comment #27 from dberlin at gcc dot gnu dot org  2007-06-05 00:12 -------
Subject: Re:  [4.3 Regression] reassoc2 can more extra calculations into a loop

On 4 Jun 2007 23:35:19 -0000, rakdver at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #26 from rakdver at gcc dot gnu dot org  2007-06-04 23:35 -------
> Created an attachment (id=13656)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13656&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13656&action=view)
> patch preventing reassociation across loop boundaries
>

You may want to turn this on only for reassoc2.
For reassoc1, we get benefit from the identities and linearization it
performs, and PRE will move out what needs to be moved out.

It's only the reassoc after loop opts are being performed that
shouldn't be playing with calculations in loops.


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

------- Comment #28 from hjl at lucon dot org  2007-06-05 00:15 -------
(In reply to comment #25)

> So probably this restriction should be applied only in reassoc2 (or reassoc2
> should be removed, if Daniel believes it is not useful).
> 

My SPEC CPU 2000 resutls in comment #18 shows reassoc2 improves some
benchmarks. I will post SPEC CPU 2006 result when it finishes.


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

------- Comment #29 from hjl at lucon dot org  2007-06-05 16:45 -------
Here are SPEC CPU 2006 -O2 -ffast-math differences between revision
125281 without the second reassoc and revision 125281 on Intel64:

                          (r125281 w/o reassoc2 - r125281)/r125281
400.perlbench                    0.492611%
401.bzip2                        0.613497%
403.gcc                          0%
429.mcf                          0%
445.gobmk                        0%
456.hmmer                        -0.787402%
458.sjeng                        1.14286%
462.libquantum                   0%
464.h264ref                      0%
471.omnetpp                      -0.869565%
473.astar                        0%
483.xalancbmk                    0.105374%
Est. SPECint(R)_base2006                 0%

410.bwaves                       1.8018%
416.gamess                       -1.14286%
433.milc                         -0.840336%
434.zeusmp                       0.657895%
435.gromacs                      -1.73348%
436.cactusADM                    -0.952381%
437.leslie3d                     -0.21692%
444.namd                         0%
447.dealII                       -2.33463%
450.soplex                       0%
453.povray                       0%
454.calculix                     -26.3852%
459.GemsFDTD                     0%
465.tonto                        0.704225%
470.lbm                          0%
481.wrf                          8.9613%
482.sphinx3                      0%
Est. SPECfp(R)_base2006                  -1.51515%


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

------- Comment #30 from hjl at lucon dot org  2007-06-07 03:16 -------
(In reply to comment #26)
> Created an attachment (id=13656)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13656&action=view) [edit]
> patch preventing reassociation across loop boundaries
> 

Here are SPEC CPU 2K -O2 -ffast-math differences between revision
125281 plus this patch and revision 125027 on Intel64 C2D:

                          (r125281 plus this patch - r125027)/r125027

400.perlbench                    0.492611%
401.bzip2                        0.613497%
403.gcc                          0%
429.mcf                          -0.666667%
445.gobmk                        0%
456.hmmer                        0%
458.sjeng                        0%
462.libquantum                   -1.0582%
464.h264ref                      -0.393701%
471.omnetpp                      0%
473.astar                        0.869565%
483.xalancbmk                    0.528541%
Est. SPECint(R)_base2006           0%

410.bwaves                       2.7027%
416.gamess                       -2.27273%
433.milc                         0%
434.zeusmp                       0%
435.gromacs                      0.433369%
436.cactusADM                    -1.88679%
437.leslie3d                     0%
444.namd                         0%
447.dealII                       -2.33463%
450.soplex                       0%
453.povray                       -0.492611%
454.calculix                     1.98151%
459.GemsFDTD                     0.961538%
465.tonto                        1.40845%
470.lbm                          0.70922%
481.wrf                          9.07238%
482.sphinx3                      0%
Est. SPECfp(R)_base2006            0.757576%


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at gcc dot gnu dot org]

------- Comment #31 from hjl at gcc dot gnu dot org  2007-09-08 06:47 -------
Subject: Bug 32183

Author: hjl
Date: Sat Sep  8 06:46:53 2007
New Revision: 128262

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128262
Log:
2007-09-07  Zdenek Dvorak  <ook@ucw.cz>

        PR tree-optimization/32183
        * Makefile.in (tree-ssa-reassoc.o): Also depend on $(CFGLOOP_H).

        * tree-ssa-reassoc.c: Include cfgloop.h.
        (is_reassociable_op): Add a loop argument and return true only
        for inside loop.
        (linearize_expr): Updated.
        (should_break_up_subtract): Likewise.
        (linearize_expr_tree): Likewise.
        (init_reassoc): Call loop_optimizer_init with
        AVOID_CFG_MODIFICATIONS.  Remove calculate_dominance_info call
        with CDI_DOMINATORS.
        (fini_reassoc): Call loop_optimizer_finalize.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/tree-ssa-reassoc.c


-- 


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

------- Comment #32 from hjl at lucon dot org  2007-10-10 04:07 -------
Fixed.


-- 

hjl at lucon dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[steven at gcc dot gnu dot org]

------- Comment #33 from steven at gcc dot gnu dot org  2007-10-10 08:57 -------
What happened with the suggestion to only do this in reassoc2 (see comment
#27)?


-- 


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

Re: [Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[Daniel Berlin]

On 10 Oct 2007 08:58:00 -0000, steven at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #33 from steven at gcc dot gnu dot org  2007-10-10 08:57 -------
> What happened with the suggestion to only do this in reassoc2 (see comment
> #27)?
>
>
Yeah, i'm not sure why we just made both reassocs more expensive when
we only care what happens with the second.

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[dberlin at dberlin dot org]

------- Comment #34 from dberlin at gcc dot gnu dot org  2007-10-10 17:43 -------
Subject: Re:  [4.3 Regression] reassoc2 can more extra calculations into a loop

On 10 Oct 2007 08:58:00 -0000, steven at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #33 from steven at gcc dot gnu dot org  2007-10-10 08:57 -------
> What happened with the suggestion to only do this in reassoc2 (see comment
> #27)?
>
>
Yeah, i'm not sure why we just made both reassocs more expensive when
we only care what happens with the second.


-- 


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