From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57146 invoked by alias); 15 Apr 2015 11:07:24 -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 57112 invoked by uid 89); 15 Apr 2015 11:07:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vn0-f44.google.com Received: from mail-vn0-f44.google.com (HELO mail-vn0-f44.google.com) (209.85.216.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 15 Apr 2015 11:07:21 +0000 Received: by vnbg129 with SMTP id g129so13581133vnb.4 for ; Wed, 15 Apr 2015 04:07:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.35.42 with SMTP id e10mr19917067oej.26.1429096039460; Wed, 15 Apr 2015 04:07:19 -0700 (PDT) Received: by 10.202.229.72 with HTTP; Wed, 15 Apr 2015 04:07:19 -0700 (PDT) In-Reply-To: <552CA415.5060206@redhat.com> References: <20150310150027.GC27860@msticlxl57.ims.intel.com> <8761a22ecm.fsf@googlemail.com> <552CA415.5060206@redhat.com> Date: Wed, 15 Apr 2015 11:07:00 -0000 Message-ID: Subject: Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386 From: Ilya Enkovich To: Jeff Law Cc: gcc-patches , rdsandiford@googlemail.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00743.txt.bz2 2015-04-14 8:22 GMT+03:00 Jeff Law : > 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? At this point I don't insist on a target hook. The main reasoning was to not affect other targets. If we extend propagation for non constant values different aspects may appear. E.g. possible register pressure changes may significantly affect ia32. I just wanted to have an instrument to play with a propagation on x86 not affecting other targets. I don't have an opportunity to test possible performance implications on non-x86 targets. Don't expect (significant) regressions there but who knows... I'll remove the hook from this patch. Will probably introduce it later if some target specific cases are found. Thanks, Ilya > > Jeff