This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: inlining inefficiencies
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Kurt Garloff <garloff at suse dot de>
- Cc: Dan Nicolaescu <dann at godzilla dot ICS dot UCI dot EDU>, <gcc at gcc dot gnu dot org>,Andreas Jaeger <aj at suse dot de>
- Date: Thu, 30 May 2002 09:08:40 -0400 (EDT)
- Subject: Re: inlining inefficiencies
On Thu, 30 May 2002, Kurt Garloff wrote:
> Hi Dan,
>
> On Wed, May 29, 2002 at 10:31:46PM -0700, Dan Nicolaescu wrote:
> > Andreas Jaeger <aj@suse.de> writes:
> >
> > > Can you have a look at Kurt Garloff's patches which have been
> > > discussed here some weeks agao? A current version is at
> > > http://www.garloff.de/kurt/freesoft/gcc/
> >
> > Those patches deal with deciding what functions to inline.
> > What I've shown is that the code generated after inlining all the
> > functions (desired in that case) is inefficient and the optimizers
> > can't deal with it.
>
> The problem that I spotted in gcc is that it's unable to remove
> temporaries too often. I have some Matrix class whose [] operator
> return a temporary object, basically having a pointer to the
> Matrix and the information which line was selected. This can
> be used to create a Vector or an element with a second [] and
> the temporary should be removed by the compiler.
Just out of curiosity, does the patch I posted yesterday to make the
inliner
generate proper statement expressions help at all?
There is code that depends on seeing proper statement expressions in order
to determine whether it should copy the result to a register, etc, or not,
and it is possible (though i'm not sure how likely) that some of the
inefficiencies you are seeing are because it's not activating this code,
and instead, generating lots of stores or something.
It's a shot in the dark, but i wouldn't be *completely* surprised if it
helped.
--Dan
> Regards,
>