From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28711 invoked by alias); 19 Jan 2003 15:34:30 -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 28616 invoked from network); 19 Jan 2003 15:34:29 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by 172.16.49.205 with SMTP; 19 Jan 2003 15:34:29 -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 18aHSc-0002Ot-00 for gcc@gcc.gnu.org; Sun, 19 Jan 2003 10:34:10 -0500 Received: from tornado.toronto.redhat.com (IDENT:3R8qGCT6wEhKun0/D/XKvMV89e9h3jJD@tornado.toronto.redhat.com [172.16.14.228]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h0JFVqg14370; Sun, 19 Jan 2003 10:31:52 -0500 Received: from tornado.toronto.redhat.com (localhost [127.0.0.1]) by tornado.toronto.redhat.com (8.12.5/8.12.5) with ESMTP id h0JFVjpw011293; Sun, 19 Jan 2003 10:31:46 -0500 Received: (from dnovillo@localhost) by tornado.toronto.redhat.com (8.12.5/8.12.5/Submit) id h0JFViVn011291; Sun, 19 Jan 2003 10:31:44 -0500 Date: Sun, 19 Jan 2003 20:49:00 -0000 From: Diego Novillo To: Alexandre Oliva Cc: Carlo Wood , Michel LESPINASSE , Andrew Haley , gcc@gcc.gnu.org Subject: Re: issues with inlining Message-ID: <20030119153138.GA11146@tornado.toronto.redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Organization: Red Hat Canada X-SW-Source: 2003-01/txt/msg00903.txt.bz2 On Sun, 19 Jan 2003, Alexandre Oliva wrote: > > 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. > Right now, the tree optimizers are run after inlining has taken place. This is convenient for us because we still can't do IPA properly. Long term we should teach the tree optimizers to work across procedures, but that is still a ways off. Diego.