--- Comment #28 from hubicka at gcc dot gnu dot org 2005-10-31 18:36
---
I get 0m8.052s on 3.4 and 0m8.127s on mainline on Athlon. This hardly counts
as an regression.
This is actually effect of some cost tweaks we did relatie to gimplifier a
while ago.
Reduced testcase fits in limits
--- Comment #29 from hubicka at gcc dot gnu dot org 2005-10-31 19:15
---
Actually I have to reopen this. When playing around on pentiumM or opteron, I
still get roughly 20% regression (6s to 8s), 4.1 and 4.0 scores are about the
same on both machines. For some reason this don't
--- Comment #27 from mmitchel at gcc dot gnu dot org 2005-10-31 00:37
---
It seems unlikely to me that this is going to be release-critical, so I've
downgraded it to P4.
Our inlining heuristics are notoriously easy to perturb. Probably, to do
substantially better, we'll need a more
--- Comment #26 from steven at gcc dot gnu dot org 2005-10-29 22:36 ---
Waiting for someone to look into this...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
What|Removed |Added
Target Milestone|4.0.2 |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
--
What|Removed |Added
Target Milestone|4.0.1 |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
--- Additional Comments From danalis at cis dot udel dot edu 2005-06-30
22:16 ---
I'm looking at the reduced testcase from comment #6,
and I noticed that f() is declared double, but does not return anything.
Thus the code doesn't compile with -O3 -Wall -Werror.
If I fix the bug adding a
--- Additional Comments From danalis at cis dot udel dot edu 2005-06-30
22:24 ---
I meant to say return(*ap1) not return(return *ap1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
--- Additional Comments From dank at kegel dot com 2005-07-01 03:44 ---
Anthony, it looks like the runtimes with the fix
match the runtimes from the larger testcase reasonably
well; at least they're faster on gcc-3.4.3 where they're
supposed to be.
So maybe we should try to answer the
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-27
06:38 ---
As you can see from those numbers Dan Kegel posted, this kind of test case
is very sensitive to the intermediate representation presented to the inliner
and to inliner heuristics. Personally, I don't
--- Additional Comments From dank at kegel dot com 2005-06-27 04:54 ---
I just verified the regression here with -march=pentium on a pentium 4.
On the original testcase, I got runtimes of 7.0, 4.9, 8.1, and 7.0
seconds with gcc-2.95.3, gcc-3.4.3, gcc-4.0.0, and gcc-4.1-20050603
using
--
What|Removed |Added
Target Milestone|4.0.0 |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-05
18:49 ---
Even with Richard Guenther's patches, the only thing that really helps is
setting --param large-function-growth=200, or more. The default is 100.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-03-05 19:03 ---
Subject: Re: [4.0/4.1 Regression] threefold
performance loss, not inlining as much
steven at gcc dot gnu dot org wrote:
--- Additional Comments From steven at gcc dot gnu dot org
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-02
11:35 ---
Performance bugs are never critical.
--
What|Removed |Added
Severity|critical
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-02
11:36 ---
Updated patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01796.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
16 matches
Mail list logo
