http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
--- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-23
14:36:33 UTC ---
Author: rguenth
Date: Mon May 23 14:36:28 2011
New Revision: 174068
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174068
Log:
2011-05-23 Richard
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-07-29 08:06
---
I'll take this for now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenther at suse dot de 2009-07-29 08:05 ---
Subject: Re: Function object abstraction penalty
with inline functions.
On Tue, 28 Jul 2009, paolo dot carlini at oracle dot com wrote:
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-28 19:38
--- Comment #11 from hubicka at ucw dot cz 2009-07-29 08:08 ---
Subject: Re: Function object abstraction penalty with inline functions.
I'll take this for now.
My preferred way of fixing this would be to include FRE pass.
Unfortunately my last benchmarks adding FRE early wasn't
--- Comment #12 from rguenther at suse dot de 2009-07-29 08:12 ---
Subject: Re: Function object abstraction penalty
with inline functions.
On Tue, 28 Jul 2009, jamborm at gcc dot gnu dot org wrote:
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-07-28 21:33
---
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-29 10:16
---
(In reply to comment #12)
... at least scheduling FRE is still on the list of possible things
todo (can you check if that fixes 3713 as well?)
No, it doesn't (unlike the testcase above, for which FRE is
--- Comment #14 from rguenther at suse dot de 2009-07-29 10:57 ---
Subject: Re: Function object abstraction penalty
with inline functions.
On Wed, 29 Jul 2009, jamborm at gcc dot gnu dot org wrote:
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-29 10:16
---
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-28 11:22 ---
After early SRA we get
f$x_8 = g;
D.2142_6 = f$x_8;
D.2141_7 = D.2142_6 (3);
which now misses a constant propagation of g into the call which is why
inlining doesn't catch this opportunity. Put one in and
--- Comment #6 from dave at boost-consulting dot com 2009-07-28 18:42
---
The next step would be to verify that the penalty is eliminated when using
boost::function / tr1::function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-28 19:38
---
One step at a time, Dave ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-07-28 21:33 ---
I can confirm that if we schedule pass_ccp right after pass_sra_early,
g gets inlined. Moreover, if we schedule one more pass_forwprop right
afterwards, even the testcase for PR 3713, comment #12 gets optimized
as
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-27 15:45 ---
(In reply to comment #1)
So one problem is that nothing after SRA (before inlining) constant props g
into the call expression.
So there is no abstraction penalty really just a missing inlining.
--
pinskia at
--- Comment #3 from dave at boost-consulting dot com 2009-07-27 16:26
---
The missing inlining is the cause, abstraction penalty is the symptom.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-27 17:57
---
I would say let's add Martin (and Honza) in CC, he did a lot of improvements
for similar issues (which I pointed out a lot of time ago to Honza).
--
paolo dot carlini at oracle dot com changed:
15 matches
Mail list logo
