From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22665 invoked by alias); 16 Dec 2006 16:32:05 -0000 Received: (qmail 22657 invoked by uid 22791); 16 Dec 2006 16:32:04 -0000 X-Spam-Check-By: sourceware.org Received: from atrey.karlin.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 16 Dec 2006 16:31:55 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 29025) id F1217C7AB4; Sat, 16 Dec 2006 17:31:50 +0100 (CET) Date: Sat, 16 Dec 2006 16:32:00 -0000 From: Zdenek Dvorak To: Richard Guenther Cc: gcc-patches@gcc.gnu.org Subject: Re: Patch ping Message-ID: <20061216163150.GA7007@atrey.karlin.mff.cuni.cz> References: <20061214235319.GA15142@atrey.karlin.mff.cuni.cz> <84fc9c000612150512g7b7bebedvc9ef8c79ea22d4a2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84fc9c000612150512g7b7bebedvc9ef8c79ea22d4a2@mail.gmail.com> User-Agent: Mutt/1.5.9i 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/msg01164.txt.bz2 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? the reason I decided to expose this parameter everywhere is that this way, tree_num_loop_insns can also be parametrized on what metrics we do want to use (without need to create three versions of this function). I can create the wrappers if you prefer anyway, although I think it would be a bit confusing. Zdenek > 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.