From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130235 invoked by alias); 16 May 2019 03:53:22 -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 130225 invoked by uid 89); 16 May 2019 03:53:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=H*MI:9acd X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 May 2019 03:53:20 +0000 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4G3qHmt182724 for ; Wed, 15 May 2019 23:53:17 -0400 Received: from e06smtp02.uk.ibm.com (e06smtp02.uk.ibm.com [195.75.94.98]) by mx0b-001b2d01.pphosted.com with ESMTP id 2sgv6t8fv6-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 15 May 2019 23:53:17 -0400 Received: from localhost by e06smtp02.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 16 May 2019 04:53:15 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp02.uk.ibm.com (192.168.101.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 16 May 2019 04:53:13 +0100 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x4G3rC6q43057262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 May 2019 03:53:13 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C196111C06E; Thu, 16 May 2019 03:53:12 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E6C0511C050; Thu, 16 May 2019 03:53:09 +0000 (GMT) Received: from kewenlins-mbp.cn.ibm.com (unknown [9.200.147.181]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 16 May 2019 03:53:09 +0000 (GMT) Subject: Re: [PATCH v2 3/3] Consider doloop cmp use in ivopts To: Richard Biener Cc: Richard Biener , GCC Patches , Segher Boessenkool , Bill Schmidt , "bin.cheng" , Jakub Jelinek References: <1557803406-123657-1-git-send-email-linkw@linux.ibm.com> <368b8ca4-dbae-b88c-23b3-dbae2bfd0dee@linux.ibm.com> From: "Kewen.Lin" Date: Thu, 16 May 2019 03:53:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit x-cbid: 19051603-0008-0000-0000-000002E7298C X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19051603-0009-0000-0000-00002253CC05 Message-Id: X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00904.txt.bz2 on 2019/5/15 下午4:47, Richard Biener wrote: > On Wed, 15 May 2019, Kewen.Lin wrote: > >> on 2019/5/14 下午3:26, Richard Biener wrote: >>> On Tue, May 14, 2019 at 5:10 AM wrote: >>>> >>>> From: Kewen Lin >>>> >>>> Previous version link for background: >>>> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html >>>> >>>> Firstly, it's to call predict_doloop_p hook to check this >>>> loop will be transformed to doloop or not, if yes, find >>>> the expected comp iv use and its dependent original iv, >>>> set the iv candidate as bind_cand of the group. >>>> In following candidate selection process, we will bypass >>>> the group with bind_cand, since we don't want to affect >>>> global decision making for an iv use which will be >>>> eliminated eventually. At the time of iv candidate set >>>> finalization, we will fill the cost pair for the group >>>> with bind_cand. If the bind_cand is already in the final >>>> set, then just use it. Otherwise, we can check whether one >>>> of existing final set is better and fill with that if so. >>>> >>>> Bootstrapped and regression testing passed on powerpc64le. >>>> >>>> Is it ok for trunk? >>> >>> I wonder what prevents IVOPTs to consider a counter IV >>> (eventually such candidate needs to be added if that's not >>> already done) to be the most profitable variant w/o any >>> of the other changes? I guess that would be costing of >>> the IV adjust plus branch which we would need to lower >>> in case there's nothing inside the loop that would make >>> later doloop transform fail? >>> >>> Richard. >>> >> >> If the question is for "w/o this patch", I think IVOPTs >> can find counter IV as the most profitable one for the cmp >> use in most time. But the key issue is that it may stop >> us to bring in more iv cands. We have to add on iv cost >> of new cand desirable for some iv use, it's probably more >> than the cost of just using counter IV for the interest >> use. >> >> If the question is for "w/i this patch", since we bypass >> the doloop cmp use in candidate determination algorithm, >> it's possible that some other iv cands are preferred for >> the remaining uses rather than the counter IV. For example, >> for some address type iv use, iv cand with memory based is >> mostly better. > > Ah, so the key issue is that the doloop IV is "free"? That > is, it doesn't consume a general register and whatnot? That > is allocating this IV doesn't really interfere with other IVs? > But can other uses be based on the doloop IV easily (if the > IV doesn't reside in a general reg?)? Yes, it takes one special hardware register "counter register" on Power. For other uses based on doloop IV, if there are no more suitable IVs, we still need one general reg for update and use. In the current patch, although we bypass this doloop cmp use, it's still allowed to have other uses to choose this doloop IV candidate. The costing is as usual. Since the doloop cmp use is actually free, we don't want ivopts to consider it and affect optimal IV set. > > Otherwise I understand that IVOPTs doesn't properly cost > the doloop IV update and conditional branch. That's clearly > something we should fix (maybe even indepenently on other > changes). One important thing is that we need to base costs > on a common base to not compare apples and oranges, didn't > dig into your patch in detail enough to see whether it > fits into the general cost model or whether it is a hack > ontop of everything. > In the previous version of patch, it's to make this doloop cmp use as zero cost with any iv cands (like it's invisible), sounds better fit in general cost model? But it requires us to preserve the doloop IV incase it's not chosen. The current version is to bind the doloop IV at the first place, bypass the choosing process and fill it directly if no better found later. For Power, either zero cost or bypass can coexist with the cost model framework. Thanks, Kewen > Richard. >