This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: inlining inefficiencies


On Thu, May 30, 2002 at 09:08:40AM -0400, Daniel Berlin wrote:
> 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.

Ditto, but my guess from reading the original message is that this is
one of the well known problems with GCC's optimizer: classes containing
a complex variable are obviously more than a word long, and thus GCC
will commit them to memory too early and too often.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]