--- Comment #58 from bonzini at gnu dot org 2009-01-31 14:26 ---
Btw, on x86_64 leslie3d performance is now above that from before r126326.
Changing to 4.3 only. A separate bug (likely not a regression) should be
opened for the testcase of comment #47.
Might even be WONTFIX for 4.3.
--- Comment #36 from rguenth at gcc dot gnu dot org 2007-10-25 08:55
---
One reason why we see a regression here regarding to partitioning is that the
fortran FE now inlines allocate () producing three calls instead of one, which
spoils the partitioning heuristics:
{
void *
--- Comment #37 from pinskia at gcc dot gnu dot org 2007-10-25 10:05
---
_gfortran_runtime_error is marked as no return which means virtual operations
should not be on it. Sounds like noreturn should be the same as no vops
(maybe). You have to take care about exceptions as no return
--- Comment #38 from rguenth at gcc dot gnu dot org 2007-10-25 11:02
---
Another thing is that for all of the mem_sym_stats we collect, we _only_
consider
memory references through pointers(!), but not for example
# VUSE MPT.242_651
D.1244_380 = du.dim[0].stride;
the associated
--- Comment #39 from rguenth at gcc dot gnu dot org 2007-10-25 11:06
---
No, in general noreturn functions cannot be treated as novops. Consider
void __attribute__((noreturn,noinline)) my_main(int *ret)
{
exit(*ret);
}
int main()
{
int ret = 0;
my_main (ret);
}
without VOPs
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-10-24 15:02
---
I have a patch to fix the heuristics, but it doesn't have effect as nobody
hoists PHI nodes that have become invariant apperantly. After PRE I see
bb 100:
# HEAP.202_828 = PHI HEAP.202_747(150),
--- Comment #35 from pthaugen at gcc dot gnu dot org 2007-10-24 23:15
---
I reran leslie3d on PowerPC with --param max-aliased-vops=1. The result was
a 90% improvement over my prior revision 129550 run (218% improvement over the
original mainline run).
--
--- Comment #29 from pthaugen at gcc dot gnu dot org 2007-10-23 20:29
---
Found another example on PowerPC in the same benchmark that is not fixed by
the checked in patches. Compiled with -m32 -O2. From the loop in procedure
FLUXI:
revision 126325:
.L47:
lfd
--- Comment #30 from pthaugen at gcc dot gnu dot org 2007-10-23 20:30
---
Created an attachment (id=14402)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14402action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #27 from pthaugen at gcc dot gnu dot org 2007-10-22 21:11
---
I tried a recent mainline on PowerPC for leslie3d, revision 129550 improved
over revision 129454 by 67%.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #28 from Joey dot ye at intel dot com 2007-10-23 02:23 ---
Got similar result on x86_64, Core 2 improves 24% from 129469 to 129504. That's
great.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-10-20 09:38
---
HJ, does applying the patch from comment #6 bring back performance to 4.1 RH
level?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #26 from hjl at lucon dot org 2007-10-20 16:05 ---
(In reply to comment #25)
HJ, does applying the patch from comment #6 bring back performance to 4.1 RH
level?
It makes no difference. I saw 20% slowdown in 437.leslie3d on Intel Core
2 Duo 64bit between revision 117890
--- Comment #23 from hjl at lucon dot org 2007-10-19 22:13 ---
Gcc 4.3 revision 129493 makes 437.leslie3d 25% faster than revision 129372 on
Intel Core 2 Duo 64bit. But it is still 13% slower than gcc 4.1 Red Hat.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #24 from patchapp at dberlin dot org 2007-10-20 04:21 ---
Subject: Bug number PR32921
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01036.html
--
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-10-19 15:36
---
Subject: Bug 32921
Author: rguenth
Date: Fri Oct 19 15:36:05 2007
New Revision: 129491
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129491
Log:
2007-10-19 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-10-19 12:27
---
Subject: Bug 32921
Author: rguenth
Date: Fri Oct 19 12:27:25 2007
New Revision: 129487
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129487
Log:
2007-10-19 Richard Guenther [EMAIL PROTECTED]
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-10-19 11:26
---
Subject: Bug 32921
Author: rguenth
Date: Fri Oct 19 11:25:55 2007
New Revision: 129484
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129484
Log:
2007-10-19 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-10-19 12:40
---
Complete mess. Can of worms. Unassigning.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-10-19 16:28
---
Actually, the fix for PR33816 might have fixed this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-10-18 11:45
---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from hjl at lucon dot org 2007-10-18 20:55 ---
This patch:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01047.html
makes 437.leslie3d 10% faster on Intel Core 2 Duo 64bit. But it is still 23%
slower than gcc 4.1 Red Hat.
--
--- Comment #11 from pthaugen at gcc dot gnu dot org 2007-10-17 16:14
---
Created an attachment (id=14364)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14364action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #12 from pthaugen at gcc dot gnu dot org 2007-10-17 16:18
---
And now some comments to go with the prior attatchment...
This checkin is causing a 75% degradation on leslie3d for PowerPC. As HJ
observed earlier, it depends on a second function accessing some of the global
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-10-17 16:59
---
Can someone explain this may_alias behavior:
so we have in the IR:
# VUSE SFT.30_53
D.892_19 = qav.data;
D.893_20 = (real8[0:] *) D.892_19;
in may_alias we get a constraint of:
D.892_19 = qav
D.893_20 =
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-10-17 17:41
---
Subject: Re: [4.3 Regression] Revision 126326 causes 12% slowdown
On 17 Oct 2007 16:59:25 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #13 from pinskia at gcc dot gnu dot org
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-10-17 21:21
---
comment #12 hints at that this is really the same problem as PR32624 (which
basically says aliasing is fucked up and non-deterministic).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #9 from hjl at lucon dot org 2007-10-07 15:16 ---
Gcc 4.3 revision 128885 is much slower than gcc 4.1 redhat revision 128771
with -O2 -ffast-math on 64bit Linux/Core 2 Duo:
437.leslie3d -26.2%
--
hjl at lucon dot org changed:
What
--
hjl at lucon dot org changed:
What|Removed |Added
CC||xuepeng dot guo at intel dot
|
--- Comment #10 from hjl at lucon dot org 2007-10-07 15:19 ---
(In reply to comment #9)
Gcc 4.3 revision 128885 is much slower than gcc 4.1 redhat revision 128771
with -O2 -ffast-math on 64bit Linux/Core 2 Duo:
437.leslie3d -26.2%
The main difference between
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-28 10:02 ---
It might be a missed optimization, so it would be nice to see where the
slowdown is and what changed there wrt trees we get. (note I will not have
time to
investigate this for the next three weeks as I'm on
--- Comment #6 from hjl at lucon dot org 2007-07-28 20:51 ---
This part of the patch:
Index: tree-ssa.c
===
--- tree-ssa.c (revision 126326)
+++ tree-ssa.c (working copy)
@@ -979,11 +979,9 @@ useless_type_conversion_p
--- Comment #7 from rguenther at suse dot de 2007-07-28 20:59 ---
Subject: Re: [4.3 Regression] Revision 126326
causes 12% slowdown
On Sat, 28 Jul 2007, hjl at lucon dot org wrote:
causes this performance regression.
437.leslie3d is a big file with 19 functions. If I put each
--- Comment #8 from hjl at lucon dot org 2007-07-28 23:25 ---
(In reply to comment #7)
This sounds strange and maybe relates this to PR32624.
I tried the patch in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624#c4
It doesn't make a difference in this case. But both are related
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-28 00:32 ---
Do you know why? Because right now there is not enough information in this bug
to declare if it is a bug or not.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-28 00:32 ---
Or really a scheduling fuck up in the core 2 duo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #3 from hjl at lucon dot org 2007-07-28 00:51 ---
I also saw 13% slowdown on Opteron. It may also happen on other none-x86
processors.
This program is in Fortran. It has loops with 3-D, 4-D and 5-D arrays.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-28 01:02 ---
The patch just makes more types be the same inside GCC so if this caused a
regression, then this is a latent bug or it is the case where mem-ssa failed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
40 matches
Mail list logo
