From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2433 invoked by alias); 19 Jan 2003 14:57:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 2409 invoked from network); 19 Jan 2003 14:57:56 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by 172.16.49.205 with SMTP; 19 Jan 2003 14:57:56 -0000 Received: from nat-pool-rdu.redhat.com ([66.187.233.200] helo=lacrosse.corp.redhat.com) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18aGrq-0008RL-00 for gcc@gcc.gnu.org; Sun, 19 Jan 2003 09:56:10 -0500 Received: from free.redhat.lsd.ic.unicamp.br (aoliva.cipe.redhat.com [10.0.1.10]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h0JEsug08538; Sun, 19 Jan 2003 09:54:56 -0500 Received: from free.redhat.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.6/8.12.6) with ESMTP id h0JEt2j7018777; Sun, 19 Jan 2003 12:55:02 -0200 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.6/8.12.6/Submit) id h0JEsuxv018767; Sun, 19 Jan 2003 12:54:56 -0200 To: Carlo Wood Cc: Michel LESPINASSE , Andrew Haley , gcc@gcc.gnu.org Subject: Re: issues with inlining References: <20021219012212.GA26426@alinoe.com> <20030109193921.GB31311@zoy.org> <15901.53649.958282.305060@cuddles.cambridge.redhat.com> <20030109215002.GC31311@zoy.org> <20030109225546.GA27959@alinoe.com> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Sun, 19 Jan 2003 19:16:00 -0000 In-Reply-To: <20030109225546.GA27959@alinoe.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-01/txt/msg00899.txt.bz2 On Jan 9, 2003, Carlo Wood wrote: > 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 :/). If you expect the inline keyword to accomplish this, check your assumptions. That's not the meaning of `inline' in any Standard I've ever seen. -finline-all-functions (implied by -O3) behaves as if every single function has been declared as inline. If you use one of this options, you get what you asked for. > 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. How about your contributing this time-machine algorithm you seem to have come up with? :-) > 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?! Because we don't do many optimizations on trees yet. As we move optimization passes from RTL to trees, before function inlining, this should improve. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer