From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31664 invoked by alias); 15 Dec 2006 13:12:50 -0000 Received: (qmail 31653 invoked by uid 22791); 15 Dec 2006 13:12:48 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.175) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 15 Dec 2006 13:12:41 +0000 Received: by ug-out-1314.google.com with SMTP id s2so839623uge for ; Fri, 15 Dec 2006 05:12:38 -0800 (PST) Received: by 10.49.49.4 with SMTP id b4mr2489405nfk.1166188358124; Fri, 15 Dec 2006 05:12:38 -0800 (PST) Received: by 10.82.175.13 with HTTP; Fri, 15 Dec 2006 05:12:37 -0800 (PST) Message-ID: <84fc9c000612150512g7b7bebedvc9ef8c79ea22d4a2@mail.gmail.com> Date: Fri, 15 Dec 2006 13:12:00 -0000 From: "Richard Guenther" To: "Zdenek Dvorak" Subject: Re: Patch ping Cc: gcc-patches@gcc.gnu.org In-Reply-To: <20061214235319.GA15142@atrey.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061214235319.GA15142@atrey.karlin.mff.cuni.cz> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2006-12/txt/msg01105.txt.bz2 On 12/15/06, Zdenek Dvorak wrote: > Hello, > > http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01495.html > > > estimate_num_insns is currently used for several things: > > > > -- on several places (loop unrolling, unswitching, exception > > handling expansion), to estimate the size of the code > > -- in prefetching, to estimate time necessary to execute the > > code > > -- in inlining for magic heuristic (that pretends to do the > > former, but in fact turns out to be closer to the latter) > > > > Not surprisingly, it cannot work well enough for all these usages > > (in particular, the optimizations that rely on it being the size of > > the code suffer by the unrealistical values returned for calls and > > divisions). This patch makes it possible to select which of these > > three estimates should be returned (by passing the structure containing > > costs of various constructs to it). One thing that I didn't like with this patch was exposing the extra parameter at all call sites like estimate_num_insns (cfun, &eni_inlining_weights). Can we at least have wrappers around that like estimate_num_insns_for_inlining (cfun) or whatever better we come up with? Otherwise splitting the cost metrics is the only sane way to go - it's being on my todo for splitting optimize-size and optimize-speed counts for inlining as well. I think I cannot approve this change though ;) Thanks, Richard.