From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84290 invoked by alias); 16 May 2019 07:25:53 -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 84277 invoked by uid 89); 16 May 2019 07:25:53 -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= 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; Thu, 16 May 2019 07:25:52 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DDBABAD94; Thu, 16 May 2019 07:25:49 +0000 (UTC) Date: Thu, 16 May 2019 07:25:00 -0000 From: Richard Biener To: Segher Boessenkool 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 In-Reply-To: <20190515161734.GI8599@gate.crashing.org> Message-ID: References: <1557803406-123657-1-git-send-email-linkw@linux.ibm.com> <368b8ca4-dbae-b88c-23b3-dbae2bfd0dee@linux.ibm.com> <20190515161734.GI8599@gate.crashing.org> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2019-05/txt/msg00910.txt.bz2 On Wed, 15 May 2019, Segher Boessenkool wrote: > On Wed, May 15, 2019 at 10:47:31AM +0200, Richard Biener wrote: > > 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? > > That is one half of it, yes. > > > But can other uses be based on the doloop IV easily (if the > > IV doesn't reside in a general reg?)? > > Getting the value of the count reg can be expensive, that is the > other half of it. > > > 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. 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?). > > 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. > > 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). 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. Richard.