From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65531 invoked by alias); 21 May 2019 15:22:44 -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 65413 invoked by uid 89); 21 May 2019 15:22:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,MIME_CHARSET_FARAWAY,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=respond X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 May 2019 15:22:42 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E3E30309703F; Tue, 21 May 2019 15:22:35 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-8.rdu2.redhat.com [10.10.112.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 57C8C1001E86; Tue, 21 May 2019 15:22:33 +0000 (UTC) Subject: Re: [PATCH v3 2/3] Add predict_doloop_p target hook To: Richard Biener , "Kewen.Lin" Cc: Segher Boessenkool , 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: Jeff Law Openpgp: preference=signencrypt Message-ID: <663596c7-1220-03dc-7860-8f6307198160@redhat.com> Date: Tue, 21 May 2019 15:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg01409.txt.bz2 On 5/21/19 4:20 AM, 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. This had been in the back of my mind as well. I wonder how the RTL IV bits would respond to that. Jeff