public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/9767 - question on inlining functions vs. member functions
@ 2003-02-28 20:26 Jason Merrill
0 siblings, 0 replies; only message in thread
From: Jason Merrill @ 2003-02-28 20:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/9767; it has been noted by GNATS.
From: Jason Merrill <jason@redhat.com>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: rth@redhat.com, gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9767 - question on inlining functions vs. member
functions
Date: Fri, 28 Feb 2003 15:20:54 -0500
OK, the problem is with the design of the inliner. In many cases, whether
or not a function gets inlined depends on whether or not it has already
been expanded--and as a result, had inline expansion done on it. _M_write
has 14 statements before optimize_inline_calls, and 49 after, which makes
it no longer a candidate for inlining. In your explicit instantiation
testcase, instantiating the whole class instantiates _M_write before write,
so _M_write can't be inlined; if you just instantiate write, _M_write has
not been expanded, so it can still be inlined.
One fix would be to keep a copy of the original function trees for use in
inlining. Optimal inlining strategy is still a topic of debate...
Jason
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2003-02-28 20:26 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-28 20:26 optimization/9767 - question on inlining functions vs. member functions Jason Merrill
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).