From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17202 invoked by alias); 3 Apr 2012 19:20:58 -0000 Received: (qmail 17191 invoked by uid 22791); 3 Apr 2012 19:20:57 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Apr 2012 19:20:44 +0000 Received: by wgbed3 with SMTP id ed3so47118wgb.8 for ; Tue, 03 Apr 2012 12:20:42 -0700 (PDT) Received: by 10.180.92.228 with SMTP id cp4mr8887666wib.2.1333480842861; Tue, 03 Apr 2012 12:20:42 -0700 (PDT) Received: from localhost (rsandifo.gotadsl.co.uk. [82.133.89.107]) by mx.google.com with ESMTPS id n15sm45095911wiw.6.2012.04.03.12.20.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 12:20:42 -0700 (PDT) From: Richard Sandiford To: Kenneth Zadeck Mail-Followup-To: Kenneth Zadeck ,gcc-patches , Ian Lance Taylor , Mike Stump , Kenneth Zadeck , avr@gjlay.de, ramana.radhakrishnan@linaro.org, rdsandiford@googlemail.com Cc: gcc-patches , Ian Lance Taylor , Mike Stump , Kenneth Zadeck , avr@gjlay.de, ramana.radhakrishnan@linaro.org Subject: Re: [C Patch]: pr52543 References: <4F67D595.9030700@naturalbridge.com> <4F6881EA.9080306@naturalbridge.com> <4F6889CC.8080302@naturalbridge.com> <4F74CFB3.5090308@naturalbridge.com> <4F75D041.4070206@naturalbridge.com> <4F772EF0.8080509@naturalbridge.com> <4F7B183A.8090903@naturalbridge.com> Date: Tue, 03 Apr 2012 19:20:00 -0000 In-Reply-To: <4F7B183A.8090903@naturalbridge.com> (Kenneth Zadeck's message of "Tue, 03 Apr 2012 11:33:14 -0400") Message-ID: <87r4w4y647.fsf@talisman.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2012-04/txt/msg00118.txt.bz2 Kenneth Zadeck writes: > Richard, > > thanks, for doing the changes. In particular, i did not really > understand how the target stuff was supposed to work. > > I have one issue with the changes that you made. > > I had actually decided that the speed/size decision was not relevant to > this patch. The problem is that since this is a global optimization > which propagates the info across the entire web of moves, you really > want/need to use the same cost metric everywhere. (of course, making > the speed/size decision on the global optimization level would be fine; > my issue is with the choice being at the bb level.) So now you are > going to have some moves in a web saying yes while others saying no. > The ones that say no will dominate. It is unlikely you will get what > you want (the important nodes really running fast) out of this, assuming > you have a target where the decision could go either way. Yeah, I suppose that's true. The problem is that both ways are wrong really. If we just use the function-level speed setting, there'll be times where a cold-only web will be optimised as hot. But as you say, if we apply the bb-level setting, cold blocks can hold back the hot blocks. And I don't particularly relish the idea of trying to joust between the two. So yeah, applying it on a function-by-function basis is probably better. Does anyone else have any thoughts before I make that change? Richard