This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: inlining inefficiencies
- From: Dan Nicolaescu <dann at godzilla dot ICS dot UCI dot EDU>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Kurt Garloff <garloff at suse dot de>, gcc at gcc dot gnu dot org, Andreas Jaeger <aj at suse dot de>
- Date: Thu, 30 May 2002 08:58:00 -0700
- Subject: Re: inlining inefficiencies
- References: <Pine.LNX.4.44.0205300906440.16464-100000@dberlin.org>
Daniel Berlin <dberlin@dberlin.org> writes:
> 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?
It doesn't help the testcase I posted. The generated code is identical
before and after your patch.