From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22478 invoked by alias); 28 Feb 2003 20:26:03 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 22434 invoked by uid 71); 28 Feb 2003 20:26:02 -0000 Date: Fri, 28 Feb 2003 20:26:00 -0000 Message-ID: <20030228202602.22433.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Jason Merrill Subject: Re: optimization/9767 - question on inlining functions vs. member functions Reply-To: Jason Merrill X-SW-Source: 2003-02/txt/msg01495.txt.bz2 List-Id: The following reply was made to PR optimization/9767; it has been noted by GNATS. From: Jason Merrill To: Benjamin Kosnik 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