From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59046 invoked by alias); 23 Jul 2019 06:09:25 -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 59037 invoked by uid 89); 23 Jul 2019 06:09:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.4 required=5.0 tests=AWL,BAYES_00,MIME_CHARSET_FARAWAY,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=Pros X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Jul 2019 06:09:23 +0000 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6N670Cg010806 for ; Tue, 23 Jul 2019 02:09:21 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2twvngr3sr-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 23 Jul 2019 02:09:21 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 23 Jul 2019 07:09:19 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 23 Jul 2019 07:09:16 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x6N69Gim59441398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Jul 2019 06:09:16 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EBEBB52050; Tue, 23 Jul 2019 06:09:15 +0000 (GMT) Received: from 192.168.10.100 (unknown [9.197.230.181]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id D789E52052; Tue, 23 Jul 2019 06:09:12 +0000 (GMT) Subject: Re: [PATCH v3 3/3] PR80791 Consider doloop cmp use in ivopts To: Segher Boessenkool , Richard Biener Cc: "Bin.Cheng" , gcc-patches List , Bill Schmidt 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> From: "Kewen.Lin" Date: Tue, 23 Jul 2019 06:14:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190722214314.GJ20882@gate.crashing.org> Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 8bit x-cbid: 19072306-0028-0000-0000-00000386FDB1 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19072306-0029-0000-0000-00002447343C Message-Id: <296bcb3c-b17d-df2f-4a48-2d85d9529e20@linux.ibm.com> X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg01477.txt.bz2 Hi Segher, on 2019/7/23 ÉÏÎç5:43, 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? For the targets where the iteration count doesn't sit in its hardware count register, we may need to allow the IV to be used for other suitable uses? > You can have multiple ivs for the same loop just fine, > right? Yes. > And costs will make everything work out, if the costs are set > correctly? There are some cases requiring to do IV elimination, it might require some cost adjustment/tuning to keep this. I met this when I did pre-bind the BIV for it, if the dedicated IV has the best cost and is associated to doloop use, it probably stops the others to merge. If my understanding is correct, this is more like to transform the loop into doloop pattern earlier, the penalty of mis-predication of doloop can be more? Pros is the setup code sequence for iteration count happens in middle-end, can be optimized better (RTL misses some range info).