--- 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
On 10 Oct 2007 08:58:00 -, steven at gcc dot gnu dot org
[EMAIL PROTECTED] 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
--- 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 -, steven at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #33 from steven at gcc dot
--- 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
--- 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=gccview=revrev=128262
Log:
2007-09-07 Zdenek Dvorak [EMAIL PROTECTED]
PR
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
--- 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=13656action=view) [edit]
patch preventing reassociation across loop boundaries
Here are SPEC CPU 2K -O2
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
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
--- 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 -, rakdver at kam dot mff dot cuni dot cz
[EMAIL PROTECTED] wrote:
--- Comment #20 from rakdver at
--- 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
--- 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=13656action=view)
patch preventing reassociation across loop boundaries
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
--- 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.
--- 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 -, rakdver at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #26 from rakdver at gcc dot
--- 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
--- 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
--- 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:
--- 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
--- 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 ;j10;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
--- 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
--
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
--- 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
--- 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
--- 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
--- 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:
30 matches
Mail list logo
