From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15108 invoked by alias); 6 Jul 2011 13:10:30 -0000 Received: (qmail 14806 invoked by uid 22791); 6 Jul 2011 13:10:29 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Jul 2011 13:10:09 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 89CFF8A95F; Wed, 6 Jul 2011 15:10:07 +0200 (CEST) Date: Wed, 06 Jul 2011 13:10:00 -0000 From: Michael Matz To: Richard Sandiford Cc: gcc@gcc.gnu.org Subject: Re: Help with ivopts In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes 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/msg00053.txt.bz2 Hi, 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. > 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). Ciao, Michael.