From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65955 invoked by alias); 23 Jul 2019 07:38:33 -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 65929 invoked by uid 89); 23 Jul 2019 07:38:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,MIME_CHARSET_FARAWAY,SPF_PASS autolearn=ham version=3.3.1 spammy=H*c:HHHHHHHHH, H*c:HHHHH, HX-Languages-Length:1880 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:38:32 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id C01E9AFA9; Tue, 23 Jul 2019 07:38:29 +0000 (UTC) Date: Tue, 23 Jul 2019 08:05:00 -0000 From: Richard Biener To: "Kewen.Lin" cc: Segher Boessenkool , "Bin.Cheng" , gcc-patches List , Bill Schmidt Subject: Re: [PATCH v3 3/3] PR80791 Consider doloop cmp use in ivopts In-Reply-To: <1cbbf9ea-69b5-b323-fb6a-3896fb3961f3@linux.ibm.com> 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> <1cbbf9ea-69b5-b323-fb6a-3896fb3961f3@linux.ibm.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1609908220-947262950-1563867509=:30921" X-SW-Source: 2019-07/txt/msg01481.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609908220-947262950-1563867509=:30921 Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 8BIT Content-length: 1829 On Tue, 23 Jul 2019, Kewen.Lin wrote: > on 2019/7/22 ÏÂÎç3:18, 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...). > > > > Hi Richard, > > Really appreciate your comments on this, very sorry not to go with this. > Since this patch is for TARGET_HAVE_COUNT_REG_DECR_P, I was thinking > it's fairly enough to reuse the existing IV cands and just zeroing doloop > use cost with them. I'm very happy to unify it. If you/Segher/Bin don't > have any concerns, I'd like to make it as one follow up item. > > One thing to double check is this dedicated IV will follow decrement > instead of increment align with doloop optimize? Then it looks to shape > the loop closing to doloop pattern, at least it's decrement. I think doloop support should be as "simple" as always adding a candidate starting from niter (-1?), step -1 marked as DOLOOP_IV (which is then used in costing, making uses in the IV update and the compare zero cost and uses in other places according to the target by using an appropriate hardreg for the fake RTL we create). IV costing and elimination should then choose the doloop IV if that's profitable. Richard. ---1609908220-947262950-1563867509=:30921--