From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69040 invoked by alias); 21 May 2019 09:58: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 68860 invoked by uid 89); 21 May 2019 09:58:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=required! 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, 21 May 2019 09:58:31 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 2C4CBABD7; Tue, 21 May 2019 09:58:29 +0000 (UTC) Date: Tue, 21 May 2019 09:58:00 -0000 From: Richard Biener To: Segher Boessenkool cc: Jeff Law , Kewen Lin , gcc-patches@gcc.gnu.org, wschmidt@linux.ibm.com, bin.cheng@linux.alibaba.com, jakub@redhat.com Subject: Re: [PATCH v3 2/3] Add predict_doloop_p target hook In-Reply-To: <20190520163759.GY31586@gate.crashing.org> Message-ID: References: <1558064130-111037-1-git-send-email-linkw@linux.ibm.com> <20190520102439.GT31586@gate.crashing.org> <20190520163759.GY31586@gate.crashing.org> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1609908220-2064982700-1558432709=:10704" X-SW-Source: 2019-05/txt/msg01368.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-2064982700-1558432709=:10704 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-length: 1873 On Mon, 20 May 2019, 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. Yes - my thinking was that if IVOPTs _not_ choose a doloop IV then the RTL side has to give up, so that's bad. But if it chooses a doloop IV but we end up failing to do a doloop that's not too bad. After all we indeed cannot remove RTL doloop analysis at this point. So the important thing is to make IVOPTs create a separate counter IV that is only used in the update/compare/branch and cost that appropriately (not even sure if _that_ is actually required!). A slight complication might be that if IVOPTs decides to use a doloop IV but creates another equivalent IV for other uses then later CSE might end up unifying them again. We should probably make IVOPTs aware of this. > Kewen, Bin, will that work satisfactorily do you think? > > > Segher > -- Richard Biener SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg) ---1609908220-2064982700-1558432709=:10704--