From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117741 invoked by alias); 22 May 2019 02:07:32 -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 117708 invoked by uid 89); 22 May 2019 02:07:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,MIME_CHARSET_FARAWAY,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:192.168.10 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; Wed, 22 May 2019 02:07:28 +0000 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4M26lp1027470 for ; Tue, 21 May 2019 22:07:25 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0b-001b2d01.pphosted.com with ESMTP id 2sms0hyxh0-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 21 May 2019 22:07:25 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 May 2019 03:07:23 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp04.uk.ibm.com (192.168.101.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 22 May 2019 03:07:20 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x4M27JHm58982548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 May 2019 02:07:19 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8CBDE52050; Wed, 22 May 2019 02:07:19 +0000 (GMT) Received: from 192.168.10.102 (unknown [9.197.225.133]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 0BC695204E; Wed, 22 May 2019 02:07:16 +0000 (GMT) Subject: Re: [PATCH v3 2/3] Add predict_doloop_p target hook To: Richard Biener Cc: Segher Boessenkool , Jeff Law , gcc-patches@gcc.gnu.org, wschmidt@linux.ibm.com, bin.cheng@linux.alibaba.com, jakub@redhat.com References: <1558064130-111037-1-git-send-email-linkw@linux.ibm.com> <20190520102439.GT31586@gate.crashing.org> <20190520163759.GY31586@gate.crashing.org> From: "Kewen.Lin" Date: Wed, 22 May 2019 02:07: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=gbk Content-Transfer-Encoding: 8bit x-cbid: 19052202-0016-0000-0000-0000027E2879 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19052202-0017-0000-0000-000032DB16FB Message-Id: <8927e278-32a2-4f6f-0148-7c71ccd3ec04@linux.ibm.com> X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg01452.txt.bz2 on 2019/5/21 ÏÂÎç6:20, Richard Biener wrote: > On Tue, 21 May 2019, Kewen.Lin wrote: > >> on 2019/5/21 ÉÏÎç12:37, Segher Boessenkool wrote: >>> On Mon, May 20, 2019 at 08:43:59AM -0600, Jeff Law wrote: >>>>> I think we should have two hooks: one is called with the struct loop as >>>>> parameter; and the other is called for every statement in the loop, if >>>>> the hook isn't null anyway. Or perhaps we do not need that second one. >>>> I'd wait to see a compelling example from real world code where we need >>>> to scan the statements. Otherwise we're just dragging in more target >>>> specific decisions which in fact we want to minimize target stuff. >>> >>> The ivopts pass will be too optimistic about what loops will end up as a >>> doloop, and cost things accordingly. The cases where we cannot later >>> actually use a doloop are doing pretty much per iteration, so I think >>> ivopts will still make good decisions. We'll need to make the rtl part >>> not actually do a doloop then, but we probably still need that logic >>> anyway. >>> >>> Kewen, Bin, will that work satisfactorily do you think? >>> >> >> If my understanding on this question is correct, IMHO we should try to make >> IVOPTs conservative than optimistic, since once the predict is wrong from >> too optimistic decision, the costing on the doloop use is wrong, it's very >> possible to affect the global optimal set. It looks we don't have any ways >> to recover it in RTL then? (otherwise, there should be better place to fix >> the PR). Although it's also possible to miss some good cases, it's at least >> as good as before, I'm inclined to make it conservative. > > I wonder if you could simply benchmark what happens if you make > IVOPTs _always_ create a doloop IV (if possible)? I doubt the > cases where a doloop IV is bad (calls, etc.) are too common and > that in those cases the extra simple IV hurts. > OK. I'll do the changes and measure with SPEC2017. Maybe also extend it to two other checks niter cost check and estimated niter range check. It may take some days. You might have to expect late response. :) Thanks Kewen > Richard. >