From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20761 invoked by alias); 31 May 2011 13:03:42 -0000 Received: (qmail 20745 invoked by uid 22791); 31 May 2011 13:03:41 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,TW_EG X-Spam-Check-By: sourceware.org Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 May 2011 13:03:03 +0000 Received: by wwi18 with SMTP id 18so2361577wwi.2 for ; Tue, 31 May 2011 06:03:02 -0700 (PDT) Received: by 10.227.19.132 with SMTP id a4mr1685645wbb.100.1306846981998; Tue, 31 May 2011 06:03:01 -0700 (PDT) Received: from richards-thinkpad (gbibp9ph1--blueice2n1.emea.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id ej7sm28445wbb.53.2011.05.31.06.03.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 06:03:00 -0700 (PDT) From: Richard Sandiford To: Tom de Vries Mail-Followup-To: Tom de Vries ,Zdenek Dvorak , gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Cc: Zdenek Dvorak , gcc-patches@gcc.gnu.org Subject: Re: [PATCH PR45098, 4/10] Iv init cost. References: <4DD21F6E.4050308@codesourcery.com> <4DD22110.1040001@codesourcery.com> <4DD3F8E9.6000004@codesourcery.com> <4DDE3D82.3010908@codesourcery.com> Date: Tue, 31 May 2011 15:22:00 -0000 In-Reply-To: <4DDE3D82.3010908@codesourcery.com> (Tom de Vries's message of "Thu, 26 May 2011 13:46:10 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (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: 2011-05/txt/msg02426.txt.bz2 Hi Tom, Thanks for the reply, and sorry for responding so slowly. Tom de Vries writes: > On 05/25/2011 03:44 PM, Richard Sandiford wrote: >> Sorry for being so late. I was just curious... >> >> Tom de Vries writes: >>> The init cost of an iv will in general not be zero. It will be >>> exceptional that the iv register happens to be initialized with the >>> proper value at no cost. In general, there will at the very least be a >>> regcopy or a const set. >>> >>> 2011-05-05 Tom de Vries >>> >>> PR target/45098 >>> * tree-ssa-loop-ivopts.c (determine_iv_cost): Prevent >>> cost_base.cost == 0. >>> Index: gcc/tree-ssa-loop-ivopts.c >>> =================================================================== >>> --- gcc/tree-ssa-loop-ivopts.c (revision 173380) >>> +++ gcc/tree-ssa-loop-ivopts.c (working copy) >>> @@ -4688,6 +4688,8 @@ determine_iv_cost (struct ivopts_data *d >>> >>> base = cand->iv->base; >>> cost_base = force_var_cost (data, base, NULL); >>> + if (cost_base.cost == 0) >>> + cost_base.cost = COSTS_N_INSNS (1); >>> cost_step = add_cost (TYPE_MODE (TREE_TYPE (base)), data->speed); >>> >>> cost = cost_step + adjust_setup_cost (data, cost_base.cost); >> >> ...why does this reasoning apply only to this call to force_var_cost? >> >> Richard > > force_var_cost is described as estimating the cost of forcing expression expr > into a variable. If expr is already a var, this definition is ambiguous. > If we can use the var directly, the cost is zero, but if we need a regcopy, it > should be the cost of a regcopy. > > What is special for an iv, is that we know that it is not only used but also > modified. If a var is used in or after the loop, we need a regcopy to init the > iv with that var. If that var is not used in or after the loop, we can use that > var as iv. The patch above is a heuristic that estimates that the latter > situation is the less frequent one. > > In general, we don't have such specific information, and the the cost of zero is > a good choice then. > > We could add a parameter to force_var_cost that indicates this choice, that > would perhaps be a better fix. > > As for the reasoning related to the const set, that is something that indeed > holds more general, and could be implemented in force_var_cost, which is what > you're suggesting if I understand you correctly. It was actually a genuine question. I honestly wasn't sure whether (and why) this was the only site at which a reg copy should be counted. However... > The tentative patch below explores these last 2 ideas. ...this makes things _much_ clearer to me FWIW. Thanks. Richard