From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32302 invoked by alias); 15 Nov 2016 18:22:35 -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 32280 invoked by uid 89); 15 Nov 2016 18:22:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=repeat, specialcase, proliferation, special-case 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; Tue, 15 Nov 2016 18:22:21 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id uAFIMAUj017571; Tue, 15 Nov 2016 12:22:12 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id uAFIM866017565; Tue, 15 Nov 2016 12:22:08 -0600 Date: Tue, 15 Nov 2016 18:22:00 -0000 From: Segher Boessenkool To: Kelvin Nilsen Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH,rs6000] Add built-in function support for Power9 byte instructions Message-ID: <20161115182207.GG12325@gate.crashing.org> References: <20161115111912.GC12325@gate.crashing.org> <71978567-5cfd-9d0c-7817-fee44f079874@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71978567-5cfd-9d0c-7817-fee44f079874@linux.vnet.ibm.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg01515.txt.bz2 On Tue, Nov 15, 2016 at 11:05:07AM -0700, Kelvin Nilsen wrote: > >> * config/rs6000/altivec.md (UNSPEC_CMPRB): New unspec value. > >> (UNSPEC_CMPRB2): New unspec value. > > > > I wonder if you really need both? The number of arguments will tell > > which is which, anyway? > > I appreciate your preference to avoid proliferation of special-case > unspec constants. However, it is a not so straightforward to combine > these two cases under the same constant value. The issue is that though > the two encoding conceptually represent different "numbers of > arguments", the arguments are all packed inside of a 32-bit register. > At the RTL level, it looks like the two different forms have the same > number of arguments (the same number of register operands). The > difference is which bits serve relevant purposes within the incoming > register operands. > > So I'm inclined to keep this as is if that's ok with you. Ah right, for some reason I thought the unspec had all the bounds as separate args. -ENOTENOUGHCOFFEE. [ snip ] > Thanks for catching this. I think I got endian confusion inside my head > while I was writing the above. I will rewrite these comments, below also. Note the ISA calls the bits in 32-bit registers 32..63, so that 63 is the rightmost bit in all registers. > > I wonder if we really need all these predicate expanders, if it wouldn't > > be easier if the builtin handling code did the setb itself? > > > > The reason it seems most "natural" to me use the expanders is because I > need to introduce a temporary CR scratch register between expansion and > insn matching. Also, it seems that the *setb pattern may be of more > general use in the future implementation of other built-in functions. > I'm inclined to keep this as is, but if you still feel otherwise, I'll > figure out how to avoid the expansion. The code (in rs6000.c) expanding the builtin can create two insns directly, so that you do not need to repeat this over and over in define_expands? Segher