From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45698 invoked by alias); 16 May 2019 17:35:05 -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 45689 invoked by uid 89); 16 May 2019 17:35:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=our X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 May 2019 17:35:02 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x4GHYvxa026639; Thu, 16 May 2019 12:34:58 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x4GHYuf7026638; Thu, 16 May 2019 12:34:56 -0500 Date: Thu, 16 May 2019 17:35:00 -0000 From: Segher Boessenkool To: Richard Biener Cc: "Kewen.Lin" , Richard Biener , GCC Patches , Bill Schmidt , "bin.cheng" , Jakub Jelinek Subject: Re: [PATCH v2 3/3] Consider doloop cmp use in ivopts Message-ID: <20190516173456.GP8599@gate.crashing.org> References: <1557803406-123657-1-git-send-email-linkw@linux.ibm.com> <368b8ca4-dbae-b88c-23b3-dbae2bfd0dee@linux.ibm.com> <20190515161734.GI8599@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00968.txt.bz2 On Thu, May 16, 2019 at 09:25:49AM +0200, Richard Biener wrote: > On Wed, 15 May 2019, Segher Boessenkool wrote: > > > Otherwise I understand that IVOPTs doesn't properly cost > > > the doloop IV update and conditional branch. > > > > Currently it doesn't even *know* something is or isn't a doloop. > > And yeah that matters a lot for proper costing, on all targets that > > have a doloop. > > Ah, OK. So for general handling IVOPTs would add a new > candidate kind (doloop kind) which is costed differently > at the various uses. That sounds good. > The "guessed" RTL we create for > costing also needs to properly create a proper counter reg > (IIRC it always creates pseudos right now, but here it would > need to be a hard reg so costing can properly pessimize uses > in addresses/memory?). We always use a pseudo currently; it is not turned into a hard register until after RA. Expanding as hard registers directly works really well, *if* you can put *all* uses of that hard reg into the RTl at expand time already. Indirect jumps and switch tables want to use the count register as well; this complicates things enormously. Also, sometimes a loop is mangled enough (in RTL) that it is better to use a GPR as IV. > > The different cost for a doloop is pretty easy... Might have to > > be a target hook though; on Power the decrement + compare-to-zero > > are "free", while on some other targets only the "compare" is. > > The cost for using the IV... For us we could just disallow it > > being used at all (except for the looping itself of course), but > > not sure what is optimal in general. Another hook? > > Indeed the easiest thing is to simply disallow uses of the doloop > IV outside of the increment, compare and branch (maybe have a > target hook that says whether a particular IV may be used for > a particular USE). But is that generic enough? > We'd still need to cost the spilling thing around calls of course, > but this can maybe be done incrementally. It's still RTL doloop > that ultimatively decides on the doloop use. We cannot have doloops with calls, on rs6000. This differs per target of course. We really need to get a good overview of what our various targets need. Segher