From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 82923394FC2E for ; Wed, 16 Mar 2022 21:00:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 82923394FC2E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 22GKxoBO005131; Wed, 16 Mar 2022 15:59:50 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 22GKxn4W005130; Wed, 16 Mar 2022 15:59:49 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 16 Mar 2022 15:59:49 -0500 From: Segher Boessenkool To: will schmidt Cc: gcc-patches@gcc.gnu.org, David Edelsohn , Peter Bergner Subject: Re: rs6000: RFC/Update support for addg6s instruction. PR100693 Message-ID: <20220316205949.GL614@gate.crashing.org> References: <3b4976974ca4a9e481c462ef2b9a4892f1d4174f.camel@vnet.ibm.com> <20220316181249.GK614@gate.crashing.org> <670b4207d259cd325822d8bc0c1dac9a892ee765.camel@vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <670b4207d259cd325822d8bc0c1dac9a892ee765.camel@vnet.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_NUMSUBJECT, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2022 21:00:55 -0000 On Wed, Mar 16, 2022 at 03:06:42PM -0500, will schmidt wrote: > On Wed, 2022-03-16 at 13:12 -0500, Segher Boessenkool wrote: > > (define_insn "addg6s" > > [(set (match_operand:GPR 0 "register_operand" "=r") > > (unspec:GPR [(match_operand:GPR 1 "register_operand" "r") > > (match_operand:GPR 2 "register_operand" "r")] > > UNSPEC_ADDG6S))] > > "TARGET_POPCNTD" > > "addg6s %0,%1,%2" > > [(set_attr "type" "integer")]) > > You do not need multiple unspec numbers. You can differentiate > them > > based on the modes of the arguments, already :-) > > Yeah, Thats what I thought, which is a big part of why I posted this > with RFC. :-) When I attempted this there was an issue with multiple > s (behind the GPR predicate) versus the singular "addg6s" > define_insn. > It's possible I had something else wrong there, but I'll > go back to that attempt and work in that direction. No, that is still there. One way out is to make this an unnamed pattern (like "*addg6s"). Another is to put the mode in the name, and then you probably want to make it a parameterized name as well, which then hides all that again: (define_insn "@addg6s" ... > > > +/* { dg-require-effective-target powerpc_vsx_ok } */ > > > > That is the wrong requirement. You want to test for Power7, not for > > VSX. I realise you probably copied this from elsewhere :-( (If from > > another addg6s testcase, just keep it). > > Because reasons. :-) The stanzas are copied from the nearby bcd-1.c > testcase that has a simpler test for addg6s. Given the input I'll > try to correct the stanzas here and limit how much error I carry along. If you do not improve the existing ones it may be best to just keep this the same in the new testcases as well. Consistency is a good thing. Consistent wrong is not so great of course :-) Segher