--- 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 #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 w
--- 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
D.1244_380 = du.dim[0].stride;
the associated SFT will neit
--- 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 f
--- 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 * D.102
--- 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).
--
http://gcc.gnu.org/bug
--- Comment #34 from rguenth at gcc dot gnu dot org 2007-10-24 15:19
---
Created an attachment (id=14406)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14406&action=view)
partition heuristics change
The idea is to change the statistics to make the values in the fields
match their
--- Comment #33 from rguenth at gcc dot gnu dot org 2007-10-24 15:18
---
DOM does, so scheduling another dominator pass after PRE (where alias is
re-run)
fixes the problem. One problem with partitioning is that we don't collect
statistics for symbols inside a partition, which makes all
--- 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
:
# HEAP.202_828 = PHI
:
# SMT.222_639 = PHI
# dtvol
--- Comment #31 from rguenth at gcc dot gnu dot org 2007-10-24 12:23
---
This is a partitioning issue. We allocate the same MPT to loads and stores
in a loop. Fixed with for example --param max-aliased-vops=1.
Diego, this is yours. Avoiding false aliasing of loads and stores sho
--- 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=14402&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- 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 0
--- 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 #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 #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 11789
--- 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 #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
--
http://gcc.gnu.org/bugzilla/s
--- 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 #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 #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=gcc&view=rev&rev=129491
Log:
2007-10-19 Richard Guenther <[EMAIL PROTECTED]>
--- 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 #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=gcc&view=rev&rev=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=gcc&view=rev&rev=129484
Log:
2007-10-19 Richard Guenther <[EMAIL PROTECTED]>
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- 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
AssignedT
--- 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
--- 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
--- 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
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 = D.892_19
I
--- 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
da
--- 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=14364&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--
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 #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 betw
--
hjl at lucon dot org changed:
What|Removed |Added
CC||xuepeng dot guo at intel dot
||co
--- 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|Remo
--
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 #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 #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 #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 (tr
--- 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 vacation
--- 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
--- 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 #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 #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 |Added
43 matches
Mail list logo
