From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74059 invoked by alias); 28 May 2015 22:16:03 -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 74044 invoked by uid 89); 28 May 2015 22:16:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no 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; Thu, 28 May 2015 22:16:02 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id DCE672CD7ED; Thu, 28 May 2015 22:16:00 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-36.phx2.redhat.com [10.3.113.36]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4SMFxue026174; Thu, 28 May 2015 18:15:59 -0400 Message-ID: <5567939F.9060507@redhat.com> Date: Thu, 28 May 2015 23:54:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ilya Enkovich CC: gcc-patches , 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> <552CA415.5060206@redhat.com> <20150417083445.GA6178@msticlxl57.ims.intel.com> <5535E5B1.9020309@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg02710.txt.bz2 On 05/05/2015 05:05 AM, Ilya Enkovich wrote: > 2015-04-21 8:52 GMT+03:00 Jeff Law : >> On 04/17/2015 02:34 AM, Ilya Enkovich wrote: >>> >>> On 15 Apr 14:07, Ilya Enkovich wrote: >>>> >>>> 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 >>> >>> >>> Here is a version with no hook. Bootstrapped and tested on >>> x86_64-unknown-linux-gnu. Is it OK for trunk? >>> >>> Thanks, >>> Ilya >>> -- >>> gcc/ >>> >>> 2015-04-17 Ilya Enkovich >>> >>> PR target/65103 >>> * fwprop.c (forward_propagate_into): Propagate loop >>> invariants if a target says so. >>> >>> gcc/testsuite/ >>> >>> 2015-04-17 Ilya Enkovich >>> >>> PR target/65103 >>> * gcc.target/i386/pr65103-2.c: New. >> >> It seems to me there's a key piece missing here -- metrics. >> >> When is this profitable, when is it not profitable. Just blindly undoing >> LICM seems wrong here. >> >> The first thought is to look at register pressure through the loop. I >> thought we had some infrastructure for this kind of query available. It'd >> probably be wise to re-use it. In fact, one might reasonably ask if LICM >> should have hoisted the expression to start with. >> >> >> I'd also think the cost of the constant may come into play here. A really >> cheap constant probably should not have been hoisted by LICM to start with >> -- but the code may have been written in such a way that some low cost >> constants are pulled out as loop invariants at the source level. So this >> isn't strictly an issue of un-doing bad LICM >> >> So I think to go forward we need to be working on solving the "when is this >> a profitable transformation to make". > > This patch doesn't force propagation. The patch just allows > propagation and regular fwprop cost estimation is used to compute if > this is profitable. For i386 I don't see cases when we shouldn't > propagate. We remove instruction, reduce register pressure and having > constant in memory operand is free which is reflected in address_cost > hook. Right, but you're blindly propagating. The right thing to do is look at some kind of metric to estimate when it's profitable to propagate the constant back in vs leave it hoisted out. If you look at what Kugan is doing in cprop.c, that's exactly the approach he's taking -- looking at rtx costing to determine when to propagate the constant back into the loop. It could probably be made better with some knowledge of register pressure and looking at whether or not all uses (vs just some uses) of the constant will be propagated. Jeff