From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45616 invoked by alias); 23 Jul 2019 07:32: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 45603 invoked by uid 89); 23 Jul 2019 07:32:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=fake X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Jul 2019 07:32:01 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 81AA4B0C6; Tue, 23 Jul 2019 07:31:59 +0000 (UTC) Date: Tue, 23 Jul 2019 07:38:00 -0000 From: Richard Biener To: Segher Boessenkool cc: "Kewen.Lin" , "Bin.Cheng" , gcc-patches List , Bill Schmidt Subject: Re: [PATCH v3 3/3] PR80791 Consider doloop cmp use in ivopts In-Reply-To: <20190722214314.GJ20882@gate.crashing.org> Message-ID: References: <1557803406-123657-1-git-send-email-linkw@linux.ibm.com> <2d897dc2-a01c-5005-6973-aad0c5930aa8@linux.ibm.com> <9d622cb7-2c1f-91bf-a61e-0239aa2ea8bf@linux.ibm.com> <20190722062604.GA20882@gate.crashing.org> <20190722214314.GJ20882@gate.crashing.org> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2019-07/txt/msg01480.txt.bz2 On Mon, 22 Jul 2019, Segher Boessenkool wrote: > On Mon, Jul 22, 2019 at 09:18:10AM +0200, Richard Biener wrote: > > On Mon, 22 Jul 2019, Segher Boessenkool wrote: > > > > > Hi! > > > > > > (Maybe I am missing half of the discussion -- sorry if so). > > > > > > I think we should have a new iv for just the doloop (which can have the > > > same starting value and step and type as another iv). > > > > > > Has this been considered? > > > > I was also suggesting this (maybe with too many words ;)). If > > it's a doloop target add such IV (candidate!) which has zero > > use-cost for the increment and compare but a (target configurable) > > penalty for other uses. Invasiveness of this approach is probably > > that you need to distinguish this candidate by making it a new > > kind (or maybe we can just have a specia candidate number...). > > Or just set some (boolean) flag in the candidate. > > I think it should simply not be allowed for any use except the doloop > uses at all? You can have multiple ivs for the same loop just fine, > right? And costs will make everything work out, if the costs are set > correctly? Sure. Upthread it was mentioned some targets can easily use the counter IV in other IV uses so it's really a matter of costs. That is, IVOPTs generated "fake" RTL should, for doloop IVs, choose an appropriate register so the target can do costing. Richard.