[Bug tree-optimization/27855] New: reassociation pass produces ~30% slower matrix multiplication code

[Bug tree-optimization/27855] New: reassociation pass produces ~30% slower matrix multiplication code

[uros at kss-loka dot si]

The testcase from PR target/27827 shows another problem, this time with
-ffast-math. The runtime performance of -ffast-math code drops for ~30%.

The problem could be traced down to reassociation tree pass, because the
performance jumps back when "flag_unsafe_math_optimizations" switch is disabled
by changing every occurence in tree-ssa-reassoc.c with
(flag_unsafe_math_optimizations && 0).

To see the problem, -funsafe-math-optimizations should be added to MMFLAGS in
target/27827 example Makefile:

MM4FLAGS = $(GMMFLAGS) -funsafe-math-optimizations


Current mainline gcc produces code with following results:

-O -mfpmath=387

ALGORITHM     NB   REPS        TIME      MFLOPS
=========  =====  =====  ==========  ==========

atlasmm       60   1000       0.260     1663.04

-O -msse2 -mfpmath=sse

ALGORITHM     NB   REPS        TIME      MFLOPS
=========  =====  =====  ==========  ==========

atlasmm       60   1000       0.229     1890.47


gcc with disabled reassoc pass for floating point values:

-O -mfpmath=387

ALGORITHM     NB   REPS        TIME      MFLOPS
=========  =====  =====  ==========  ==========

atlasmm       60   1000       0.162     2664.87

-O -msse2 -mfpmath=sse

ALGORITHM     NB   REPS        TIME      MFLOPS
=========  =====  =====  ==========  ==========

atlasmm       60   1000       0.164     2633.15


-- 
           Summary: reassociation pass produces ~30% slower matrix
                    multiplication code
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: uros at kss-loka dot si
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
OtherBugsDependingO 27827
             nThis:


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-06-01 15:26 -------
There is nothing special about reassociation at all.  In fact what you are
seeing is register allocator going funky.  This what you get with x87.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |target
           Keywords|                            |ra


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[uros at kss-loka dot si]

------- Comment #2 from uros at kss-loka dot si  2006-06-02 10:04 -------
(In reply to comment #1)
> There is nothing special about reassociation at all.  In fact what you are
> seeing is register allocator going funky.  This what you get with x87.

This is also what you get with SSE.


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-06-02 10:19 -------
(In reply to comment #2)
> This is also what you get with SSE.
And how many registers does SSE have, not many.  Try it on PPC or any processor
have more registers?


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[steven at gcc dot gnu dot org]

------- Comment #4 from steven at gcc dot gnu dot org  2006-06-02 23:19 -------
Real bug, despite Andrew's usual portion of x86-hate.


-- 

steven 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-06-02 23:19:36
               date|                            |


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

Re: [Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[Daniel Berlin]

steven at gcc dot gnu dot org wrote:
> ------- Comment #4 from steven at gcc dot gnu dot org  2006-06-02 23:19 -------
> Real bug, despite Andrew's usual portion of x86-hate.
> 
> 

It'd be good to know what exactly is going wrong.
Reassociation only touches floating point because someone asked me to
make it touch floating point.

It still shouldn't have *this* much of an affect, my guess is it is
triggering some bad behavior elsewhere.

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[dberlin at dberlin dot org]

------- Comment #5 from dberlin at gcc dot gnu dot org  2006-06-03 02:11 -------
Subject: Re:  reassociation pass produces ~30% slower matrix
 multiplication code

steven at gcc dot gnu dot org wrote:
> ------- Comment #4 from steven at gcc dot gnu dot org  2006-06-02 23:19 -------
> Real bug, despite Andrew's usual portion of x86-hate.
> 
> 

It'd be good to know what exactly is going wrong.
Reassociation only touches floating point because someone asked me to
make it touch floating point.

It still shouldn't have *this* much of an affect, my guess is it is
triggering some bad behavior elsewhere.


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-06-03 02:38 -------
What reassociation is doing is "scheduling" the instructions further down
before the use but it exands the life time of some variables.

e.g.:
  D.1563_59 = rA0_49 * rB0_50;
  rC0_0_60 = D.1563_59 + rC0_0_516;
  D.1564_61 = rA1_52 * rB0_50;
  rC1_0_62 = D.1564_61 + rC1_0_517;
  D.1565_63 = rA2_54 * rB0_50;
  rC2_0_64 = D.1565_63 + rC2_0_518;
  D.1566_65 = rA3_56 * rB0_50;
  rC3_0_66 = D.1566_65 + rC3_0_519;
  D.1567_67 = rA4_58 * rB0_50;
  rC4_0_68 = D.1567_67 + rC4_0_520;

into:
  D.1563_59 = rB0_50 * rA0_49;
  D.1564_61 = rA1_52 * rB0_50;
  D.1565_63 = rA2_54 * rB0_50;
  D.1566_65 = rA3_56 * rB0_50;
  D.1567_67 = rA4_58 * rB0_50;
..... (with loads, etc here)
 D.1563_477 = rB0_468 * rA0_466;
  rC0_0_60 = D.1563_59 + rC0_0_516;
  rC0_0_82 = rC0_0_60 + D.1563_81;
  rC0_0_104 = rC0_0_82 + D.1563_103;
  rC0_0_126 = rC0_0_104 + D.1563_125;
  rC0_0_148 = rC0_0_126 + D.1563_147;
  rC0_0_170 = rC0_0_148 + D.1563_169;
  rC0_0_192 = rC0_0_170 + D.1563_191;
  rC0_0_214 = rC0_0_192 + D.1563_213;
  rC0_0_236 = rC0_0_214 + D.1563_235;
  rC0_0_258 = rC0_0_236 + D.1563_257;
  rC0_0_280 = rC0_0_258 + D.1563_279;
  rC0_0_302 = rC0_0_280 + D.1563_301;
  rC0_0_324 = rC0_0_302 + D.1563_323;
  rC0_0_346 = rC0_0_324 + D.1563_345;
  rC0_0_368 = rC0_0_346 + D.1563_367;
  rC0_0_390 = rC0_0_368 + D.1563_389;
  rC0_0_412 = rC0_0_390 + D.1563_411;
  rC0_0_434 = rC0_0_412 + D.1563_433;
  rC0_0_456 = rC0_0_434 + D.1563_455;
  rC0_0_478 = rC0_0_456 + D.1563_477;


Which in of itself not supressing and not nothing which reassociate should
handle special.  This is what we get with a semi bad register allocation which
does nothing to reduce spilling.


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-06-03 02:49 -------
If you change the code to be integers, this also cause the drop too with
reassociation even without -ffast-math so it is unrelated to the fact
-ffast-math turns on reassociate for floating points for fast math. 

So what is happening is that the add to rC[0-4]_0 is being further down which
causes variable's life to be extended.  Yes there should be a pass at the tree
level which optimizes variable's life time but I don't know how much use that
is without a better register allocator in the first place.


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[steven at gcc dot gnu dot org]

------- Comment #8 from steven at gcc dot gnu dot org  2006-06-03 23:49 -------
You could add a basic block list scheduler at the tree level just before
out-of-ssa, with heuristics to make life times as short as possible :-)


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[amacleod at redhat dot com]

------- Comment #9 from amacleod at redhat dot com  2006-06-05 15:46 -------
This thread is moving dangerously close to work in progress.. :-)
I'll have something more definitive to say about it in a few weeks, but I'm
looking at doing significant register pressure reduction at out of ssa time as
a component of a larger hunk of work.


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[dberlin at gcc dot gnu dot org]

------- Comment #10 from dberlin at gcc dot gnu dot org  2006-06-05 15:57 -------
(In reply to comment #9)
> This thread is moving dangerously close to work in progress.. :-)
> I'll have something more definitive to say about it in a few weeks, but I'm
> looking at doing significant register pressure reduction at out of ssa time as
> a component of a larger hunk of work.

Just be careful. The last time i tried something like this, it produced good
code on x86, and really crappy code everywhere else.


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[steven at gcc dot gnu dot org]

------- Comment #11 from steven at gcc dot gnu dot org  2006-10-07 10:05 -------
Would anyone object if I'd propose to disable reassociation for floating point
thingies on x86 for GCC 4.2?  We can re-enable it if/when amacleod's new
out-of-ssa stuff fixes this for real...


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2006-10-07 16:36 -------
(In reply to comment #11)
> Would anyone object if I'd propose to disable reassociation for floating point
> thingies on x86 for GCC 4.2?  We can re-enable it if/when amacleod's new
> out-of-ssa stuff fixes this for real...

Yes I do because it helps PPC which is why I added in the first place.


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[ubizjak at gmail dot com]

------- Comment #13 from ubizjak at gmail dot com  2007-03-02 15:34 -------
Any news about this problem?
Current mainline still has severe problems:

-msse3 -O2 -mfpmath=sse -ffast-math
GCC 4.3 -ffast-math double performance:
ALGORITHM     NB   REPS        TIME      MFLOPS
=========  =====  =====  ==========  ==========
atlasmm       60   1000       0.288     1499.91

-msse3 -O2 -mfpmath=sse
GCC 4.3 double performance:
ALGORITHM     NB   REPS        TIME      MFLOPS
=========  =====  =====  ==========  ==========
atlasmm       60   1000       0.192     2249.86

-msse3 -O2 -mfpmath=sse -ffast-math
GCC 4.3 -ffast-math single performance:
ALGORITHM     NB   REPS        TIME      MFLOPS
=========  =====  =====  ==========  ==========
atlasmm       60   1000       0.304     1420.96

-msse3 -O2 -mfpmath=sse
GCC 4.3 single performance:
ALGORITHM     NB   REPS        TIME      MFLOPS
=========  =====  =====  ==========  ==========
atlasmm       60   1000       0.172     2511.48

Please consider the fact that all benchmarks are using -ffast-math nowadays. ;)


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2007-03-02 17:42 -------
> Please consider the fact that all benchmarks are using -ffast-math nowadays. ;)

Please also consider the fact that the register allocator has been broken since
20 years ago :) :) :) :).

And I repeat again, this has nothing to do with -ffast-math, see my comment #6
and #7 where I prove -ffast-math is not the issue and it is just the register
allocator going wrong.  If anyone disables reassociation at the tree level, I
am going to object loudly.


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[ubizjak at gmail dot com]

------- Comment #15 from ubizjak at gmail dot com  2007-07-09 18:16 -------
New timings on x86_64 core2 (from [1])

The tests were performed on core2 in 64bit mode, using '-DREPS=10000 -O3 -msse3
-march=core2 -ffast-math' flags, with and without newly introduced
-fno-tree-reassoc flag.

The results were _interesting_, showing extreme differences in the run times:

w/o -fno-tree-reassoc:

ALGORITHM     NB   REPS        TIME      MFLOPS
=========  =====  =====  ==========  ==========

-DTYPE=float:     atlasmm       60  10000       2.000     2159.87
-DTYPE=double:    atlasmm       60  10000       2.500     1727.89

w/ -fno-tree-reassoc:

ALGORITHM     NB   REPS        TIME      MFLOPS
=========  =====  =====  ==========  ==========

-DTYPE=float:     atlasmm       60  10000       0.932     4634.90
-DTYPE=double:    atlasmm       60  10000       1.520     2841.93

[1] http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00849.html


-- 


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

[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code

[uros at gcc dot gnu dot org]

------- Comment #16 from uros at gcc dot gnu dot org  2007-07-09 19:22 -------
Subject: Bug 27855

Author: uros
Date: Mon Jul  9 19:22:03 2007
New Revision: 126491

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126491
Log:
        PR target/27855
        * doc/extend.texi: Add ftree-reassoc flag.
        * common.opt (ftree-reassoc): New flag.
        * tree-ssa-reassoc.c (gate_tree_ssa_reassoc): New static function.
        (struct tree_opt_pass pass_reassoc): Use gate_tree_ssa_reassoc.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/common.opt
    trunk/gcc/doc/invoke.texi
    trunk/gcc/tree-ssa-reassoc.c


-- 


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

[Bug target/27855] [4.3 regression] reassociation pass produces ~30% slower matrix multiplication code

[ubizjak at gmail dot com]

------- Comment #17 from ubizjak at gmail dot com  2007-12-10 10:16 -------
4.3 regression according to Issue 2 at
http://gcc.gnu.org/ml/gcc/2007-11/msg00753.html.


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|reassociation pass produces |[4.3 regression]
                   |~30% slower matrix          |reassociation pass produces
                   |multiplication code         |~30% slower matrix
                   |                            |multiplication code


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

[Bug target/27855] [4.3 regression] reassociation pass produces ~30% slower matrix multiplication code

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2007-12-10 10:39 -------
I see no difference wrt -fno-tree-reassoc on x86_64 for the mmbenchv.tar.gz
benchmark.  So, which is the testcase exhibiting the problem, what is the
exact architecture and optimization flags?  (Yes, I enabled -ffast-math)


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug target/27855] [4.3 regression] reassociation pass produces ~30% slower matrix multiplication code

[ubizjak at gmail dot com]

------- Comment #19 from ubizjak at gmail dot com  2007-12-10 11:14 -------
I have tried with mmbenchs.tar.gz [1] from PR 27827:

TYPE=double:
gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math -fno-tree-reassoc:
atlasmm       60   1000       0.188     2297.73
gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math
atlasmm       60   1000       0.284     1521.04

TYPE=float:
gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math -fno-tree-reassoc
atlasmm       60   1000       0.168     2571.28
gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math
atlasmm       60   1000       0.304     1420.96

gcc version 4.3.0 20071210 (experimental) [trunk revision 130738] (GCC) 

Family: 15 Model: 4 Stepping: 10 Type: 0 Brand: 0
CPU Model: Pentium 4 D (Foster) Original OEM
Processor name string: Intel(R) Xeon(TM) CPU 3.60GHz

Please note that CPU runs in 32bit mode.

[1] http://gcc.gnu.org/bugzilla/attachment.cgi?id=12020


-- 


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

[Bug target/27855] [4.3 regression] reassociation pass produces ~30% slower matrix multiplication code

[ubizjak at gmail dot com]

------- Comment #20 from ubizjak at gmail dot com  2007-12-11 05:57 -------
Should this be tree-optimization?


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|2006-06-02 23:19:36         |2007-12-11 05:57:28
               date|                            |


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

[Bug target/27855] [4.3 regression] reassociation causes the RA to be confused

[pinskia at gcc dot gnu dot org]

------- Comment #21 from pinskia at gcc dot gnu dot org  2007-12-26 01:37 -------
As mentioned, this is really a ra issue as I showed it with integers. 
reassociation does nothing except for reschedule the instructions.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Severity|normal                      |enhancement
  GCC build triplet|i686-pc-linux-gnu           |
   GCC host triplet|i686-pc-linux-gnu           |
            Summary|[4.3 regression]            |[4.3 regression]
                   |reassociation pass produces |reassociation causes the RA
                   |~30% slower matrix          |to be confused
                   |multiplication code         |
   Target Milestone|---                         |4.3.0


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

[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2008-03-14 16:42 -------
Adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused

[rguenth at gcc dot gnu dot org]

------- Comment #23 from rguenth at gcc dot gnu dot org  2008-06-06 14:56 -------
4.3.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.1                       |4.3.2


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

[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused

[jsm28 at gcc dot gnu dot org]

------- Comment #24 from jsm28 at gcc dot gnu dot org  2008-08-27 22:01 -------
4.3.2 is released, changing milestones to 4.3.3.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.2                       |4.3.3


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

[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused

[jakub at gcc dot gnu dot org]

------- Comment #25 from jakub at gcc dot gnu dot org  2008-11-13 13:35 -------
Now that we have a new RA, is this still an issue?


-- 


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

[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused

[ubizjak at gmail dot com]

------- Comment #26 from ubizjak at gmail dot com  2008-11-13 14:52 -------
(In reply to comment #25)
> Now that we have a new RA, is this still an issue?

Yes.

TYPE=double:
gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math -fno-tree-reassoc:
atlasmm       60   1000       0.196     2203.95
gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math
atlasmm       60   1000       0.276     1565.12

TYPE=float:
gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math -fno-tree-reassoc
atlasmm       60   1000       0.160     2699.83

gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math
atlasmm       60   1000       0.232     1861.96

gcc version 4.4.0 20081113 (experimental) [trunk revision 141819] (GCC)


-- 


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

[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused

[ubizjak at gmail dot com]

------- Comment #27 from ubizjak at gmail dot com  2008-11-13 14:58 -------
I wouldn't call this problem an enhancement. Matrix computations are affected
by this problem.


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |major


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

[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused

[rguenth at gcc dot gnu dot org]

------- Comment #28 from rguenth at gcc dot gnu dot org  2009-01-24 10:19 -------
GCC 4.3.3 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused

[bonzini at gnu dot org]

------- Comment #29 from bonzini at gnu dot org  2009-02-04 07:46 -------
A similar problem was fixed with PR38533, is this still an issue?


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org
  BugsThisDependsOn|                            |38533


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

[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused

[ubizjak at gmail dot com]

------- Comment #30 from ubizjak at gmail dot com  2009-02-04 08:57 -------
(In reply to comment #29)
> A similar problem was fixed with PR38533, is this still an issue?

TYPE=double:
gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math -fno-tree-reassoc:
atlasmm       60   1000       0.208     2076.79
gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math
atlasmm       60   1000       0.272     1588.14

TYPE=float:
gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math -fno-tree-reassoc
atlasmm       60   1000       0.176     2454.39
gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math
atlasmm       60   1000       0.168     2571.28



FLOAT case is OK now, but we regressed somehow.
DOUBLE case still shows problem and runtime regression too.


-- 


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

[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused

[bonzini at gnu dot org]

------- Comment #31 from bonzini at gnu dot org  2009-02-04 11:22 -------
Created an attachment (id=17241)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17241&action=view)
source code to reproduce the bug

Code from PR27827 that still regresses (also with -DTYPE=float, so it's not a
target-specific issue; the numbers Uros posted used different code for float
and double)


-- 


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

[Bug target/27855] [4.3/4.4/4.5 regression] reassociation causes the RA to be confused

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal


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

[Bug target/27855] [4.3/4.4/4.5 regression] reassociation causes the RA to be confused

[rguenth at gcc dot gnu dot org]

------- Comment #32 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=27855

[Bug target/27855] [4.3/4.4/4.5 regression] reassociation causes the RA to be confused

[pinskia at gcc dot gnu dot org]

------- Comment #33 from pinskia at gcc dot gnu dot org  2009-09-20 20:20 -------
*** Bug 28481 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vda dot linux at googlemail
                   |                            |dot com


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

[Bug target/27855] [4.3/4.4/4.5 regression] reassociation causes the RA to be confused

[rguenth at gcc dot gnu dot org]

------- Comment #34 from rguenth at gcc dot gnu dot org  2010-01-19 16:17 -------
Re-confirmed.  -fsched-pressure -fschedule-insns helps recover some of the
performance, ivopts adds its share as well as re-association.

Scheduling is probably limited by ivopts producing TMRs and w/o ivopts
by plain INDIRECT_REFs.  None of which are handled by the alias-export to RTL.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-12-11 05:57:28         |2010-01-19 16:17:28
               date|                            |


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

[Bug target/27855] [4.3/4.4/4.5/4.6 regression] reassociation causes the RA to be confused

[rguenth at gcc dot gnu dot org]

------- Comment #35 from rguenth at gcc dot gnu dot org  2010-05-22 18:11 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

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


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