From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2840 invoked by alias); 5 Apr 2008 19:59:31 -0000 Received: (qmail 2828 invoked by uid 22791); 5 Apr 2008 19:59:30 -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, 05 Apr 2008 19:59:13 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id E6723F013C; Sat, 5 Apr 2008 21:59:10 +0200 (CEST) Date: Sat, 05 Apr 2008 20:39:00 -0000 From: Jan Hubicka To: Richard Guenther Cc: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: Patch ping... Message-ID: <20080405195910.GF28471@atrey.karlin.mff.cuni.cz> References: <20080405162606.GA22594@atrey.karlin.mff.cuni.cz> <84fc9c000804050953o429fde26jb3938827ff9dc5a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84fc9c000804050953o429fde26jb3938827ff9dc5a@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) 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: 2008-04/txt/msg00465.txt.bz2 > > I think the patch makes sense (BRANCH_COST is special anyway compared to > other isns cost), but I'd like to see the bigger picture as well here. In > particular, BRANCH_COST (hot, predictable), why isn't that simply > BRANCH_COST (optimize_size_p, predictable) matching what I possibly > expect for the other cost interface (insn_cost (optimize_size_p, rtx)). The reason is that I don't think current paradigm of optimize_size variable and profile info is good combination. We have maybe_hot_bb_p and probably_cold_bb_p that use CFG profile to guess on hotness. Their names suggest in what direction they are conservative and it defaults to preferred -O2 behaviour (ie code tends to be hot unless there is really good reason for otherwise). I would like to have hot_bb_p predicate that take into accounts the hints: 1) hot/cold function attributes 2) -Os versus optimize_size 3) function local profile (ie things guarded with __builtin_expect or leading to abort) 4) profile feedback and decide on hotness. With -Os defaulting to conservative behaviour (ie function is hot only if attribute or profile feedback suggest so) and -O2 defaulting to aggressive behaviour (function is hot if not declared cold, function local profile is within bounds). I see that hotness in 90% corelate with !optimize_size, but not in 100% cases, especially in decision affecting the whole function or unit or loop or so that might contain both hot and cold stuff. So I think hottness is more precise name for what is going on here. Honza > > Thanks, > Richard.