From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23323 invoked by alias); 14 Apr 2015 05:22:32 -0000 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 Received: (qmail 23312 invoked by uid 89); 14 Apr 2015 05:22:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 14 Apr 2015 05:22:31 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3E5MUDl021808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 14 Apr 2015 01:22:30 -0400 Received: from localhost.localdomain (ovpn-113-99.phx2.redhat.com [10.3.113.99]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3E5MTwo008494; Tue, 14 Apr 2015 01:22:29 -0400 Message-ID: <552CA415.5060206@redhat.com> Date: Tue, 14 Apr 2015 05:22:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ilya Enkovich , gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Subject: Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386 References: <20150310150027.GC27860@msticlxl57.ims.intel.com> <8761a22ecm.fsf@googlemail.com> In-Reply-To: <8761a22ecm.fsf@googlemail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00625.txt.bz2 On 03/15/2015 02:30 PM, Richard Sandiford wrote: > Ilya Enkovich writes: >> This patch allows propagation of loop invariants for i386 if propagated >> value is a constant to be used in address operand. Bootstrapped and >> tested on x86_64-unknown-linux-gnu. OK for trunk or stage 1? > > Is it necessary for this to be a target hook? The concept doesn't seem > particularly target-specific. We should only propagate into the address > if the new cost is no greater than the old cost, but if the address > meets that condition and if propagating at this point in the pipeline is > a win on x86, then wouldn't it be a win for other targets too? I agree with Richard here. I can't see a strong reason why this should be a target hook. Perhaps part of the issue here is the address costing metrics may not have enough context to make good decisions. In which case what context do they need? Jeff