From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11385 invoked by alias); 6 Jul 2011 13:32:28 -0000 Received: (qmail 11370 invoked by uid 22791); 6 Jul 2011 13:32:27 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-fx0-f49.google.com (HELO mail-fx0-f49.google.com) (209.85.161.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Jul 2011 13:32:10 +0000 Received: by fxd20 with SMTP id 20so75422fxd.22 for ; Wed, 06 Jul 2011 06:32:09 -0700 (PDT) Received: by 10.223.98.204 with SMTP id r12mr1360374fan.74.1309959128912; Wed, 06 Jul 2011 06:32:08 -0700 (PDT) Received: from richards-thinkpad (gbibp9ph1--blueice3n2.emea.ibm.com [195.212.29.84]) by mx.google.com with ESMTPS id m5sm6026273fai.1.2011.07.06.06.32.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 06:32:08 -0700 (PDT) From: Richard Sandiford To: Michael Matz Mail-Followup-To: Michael Matz ,gcc@gcc.gnu.org, richard.sandiford@linaro.org Cc: gcc@gcc.gnu.org Subject: Re: Help with ivopts References: Date: Wed, 06 Jul 2011 13:32:00 -0000 In-Reply-To: (Michael Matz's message of "Wed, 6 Jul 2011 15:10:06 +0200 (CEST)") 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-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg00054.txt.bz2 Michael Matz writes: > On Wed, 6 Jul 2011, Richard Sandiford wrote: >> The individual difference_cost and add_cost seem reasonable (4 in each >> case). I don't understand the reasoning behind the division though. Is >> the idea that this should be hoisted? > > Yes, it should be hoisted outside the loop. The difference is between two > loop-invariant values (the bases), and hence is also loop-invariant. Some > tree optimizer should do this already, possibly the casts confuse us. OK, thanks, suspected as much. >> If so, then: >> >> (a) That doesn't happen at the tree level. The subtraction is still inside >> the loop at RTL generation time. >> >> (b) What's the advantage of introducing a new hoisted subtraction that >> is going to be live throughout the loop, and then adding another IV >> to it inside the loop, over using the original IV and incrementing it >> in the normal way? > > It can reduce address complexity for one of the addresses. E.g. given: > > i=0; i < end; i+=4 > p[i]; > q[i]; > > --> > > n=p; n < p+end; n+=4 > [n]; > (q-p)[n]; > > Here (q-p) is loop-invariant, and the complexity of the first address is > lower (no offset). In fact the register pressure is lower by one too > (three instead of four, including the end/p+end bound). But your second loop isn't what I was comparing it with. I was comparing it with: n=p; n < p+end; n+=4, m+=4 [n] [m] That has the same number of registers (3) and the same number of additions (2). And the [m] is what we started with, so it was actually: i=0; i i=0; i