From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Received: (qmail 30719 invoked from network); 9 Jan 2003 22:56:01 -0000 Received: from unknown (HELO mail.alinoe.com) (24.132.80.10) by 209.249.29.67 with SMTP; 9 Jan 2003 22:56:01 -0000 Received: (qmail 28008 invoked by uid 500); 9 Jan 2003 22:55:46 -0000 Date: Fri, 10 Jan 2003 00:15:00 -0000 From: Carlo Wood To: Michel LESPINASSE Cc: Andrew Haley , gcc@gcc.gnu.org Subject: Re: issues with inlining Message-ID: <20030109225546.GA27959@alinoe.com> References: <20021219012212.GA26426@alinoe.com> <20030109193921.GB31311@zoy.org> <15901.53649.958282.305060@cuddles.cambridge.redhat.com> <20030109215002.GC31311@zoy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030109215002.GC31311@zoy.org> User-Agent: Mutt/1.4i X-SW-Source: 2003-01/txt/msg00527.txt.bz2 On Thu, Jan 09, 2003 at 01:50:02PM -0800, Michel LESPINASSE wrote: > > According to the docs > > > > `-O3' turns on all optimizations specified by `-O2' and also > > turns on the `inline-functions' option. But that says nothing about priority regulation. > > so why are you using -O3 if you want to control inlining by means of > > the "inline" kwyword? To let the compiler decide is MORE can be inlined than what I already marked as must-be-inlined (although it doesn't do that :/). > >>> 4) The instruction limit that can be set with -finline-limit > >>> seems to count instructions before optimization... > > > > True -- the inliner works at the source level before optimization is > > performed. This is the best way to do it. Of course it is best to FIRST inline and THEN optimize - but, the set instruction limit should be on the optimized result, not on on the number of instructions before optimization. > You're most probably right on average. But you sometimes see code that > use compile-time constants for specialization, i.e. one big inline > routine that evaluates to something small based on the value of some > constant parameters. In this case, the fact the inliner only sees the > huge initial routine instead of the smaller one after specialization, > combined with the fact the programmer can not use the inline keyword > to force inlining, is an issue. Exactly my point. I use HUGE template functions that go like: if (constant == 1) { ... } else if (constant == 2) { ... } etc etc. We talk about a reduction of 100 in size ONLY because of if (CONSTANT) { } constructs. The -finline-limit is really un usable when it doesn't ignore the instructions in those blocks that will not be used. Note that even with -O0 these blocks are removed... so why the need to count those instruction when deciding whether or not to inline the function?! -- Carlo Wood