From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from arjuna.pair.com (arjuna.pair.com [209.68.5.131]) by sourceware.org (Postfix) with ESMTPS id 98E323857C6E for ; Sun, 6 Sep 2020 02:47:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 98E323857C6E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bitrange.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hp@bitrange.com Received: by arjuna.pair.com (Postfix, from userid 3006) id F135D8A3A7; Sat, 5 Sep 2020 22:47:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by arjuna.pair.com (Postfix) with ESMTP id F02E48A09A; Sat, 5 Sep 2020 22:47:20 -0400 (EDT) Date: Sat, 5 Sep 2020 22:47:20 -0400 (EDT) From: Hans-Peter Nilsson X-X-Sender: hp@arjuna.pair.com To: "Bin.Cheng" cc: "Kewen.Lin" , "bin.cheng" , Segher Boessenkool , GCC Patches , Bill Schmidt , Richard Guenther Subject: Re: [PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling In-Reply-To: Message-ID: References: <16f8ae40-c0ae-dd57-346e-f9cacea55038@linux.ibm.com> <54fd03a8-0efa-af95-c929-6beb70f563ea@linux.ibm.com> <7130462d-7ffd-af0b-b62a-fb792a41762f@linux.ibm.com> User-Agent: Alpine 2.20.16 (BSF 172 2016-09-29) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2020 02:47:22 -0000 On Tue, 1 Sep 2020, Bin.Cheng via Gcc-patches wrote: > > Great idea! With explicitly specified -funroll-loops, it's bootstrapped > > but the regression testing did show one failure (the only one): > > > > PASS->FAIL: gcc.dg/sms-4.c scan-rtl-dump-times sms "SMS succeeded" 1 > > > > It exposes two issues: > > > > 1) Currently address_cost hook on rs6000 always return zero, but at least > > from Power7, pre_inc/pre_dec kind instructions are cracked, it means we > > have to take the address update into account (scalar normal operation). > > Since IVOPTs reduces the cost_step for ainc candidates, it makes us prefer > > ainc candidates. In this case, the cand/group cost is -4 (minus cost_step), > > with scaling up, the off becomes much. With one simple hack on for pre_inc/ > > pre_dec in rs6000 address_cost, the case passed. It should be handled in > > one separated issue. > > > > 2) This case makes me think we should exclude ainc candidates in function > > mark_reg_offset_candidates. The justification is that: ainc candidate > > handles step update itself and when we calculate the cost for it against > > its ainc_use, the cost_step has been reduced. When unrolling happens, > > the ainc computations are replicated and it doesn't save step updates > > like normal reg_offset_p candidates. > Though auto-inc candidate embeds stepping operation into memory > access, we might want to avoid it in case of unroll if there are many > sequences of memory accesses, and if the unroll factor is big. The > rationale is embedded stepping is a u-arch operation and does have its > cost. Forgive me for barging in here (though the context is powerpc, the dialogue and the patch seems to be generic ivopts), but that's not a general remark I hope, about auto-inc (always) having a cost? For some architectures, auto-inc *is* free, as free as register-indirect, so the more auto-inc use, the better. All this should be reflected by the address-cost, IMHO, and not hardcoded into ivopts. brgds, H-P