From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25963 invoked by alias); 25 Mar 2011 18:49:43 -0000 Received: (qmail 25947 invoked by uid 22791); 25 Mar 2011 18:49:42 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Mar 2011 18:49:29 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2PInR82026000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2011 14:49:27 -0400 Received: from anchor.twiddle.home (ovpn-113-112.phx2.redhat.com [10.3.113.112]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p2PInQgM004703; Fri, 25 Mar 2011 14:49:27 -0400 Message-ID: <4D8CE3B6.1060606@redhat.com> Date: Fri, 25 Mar 2011 19:23:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: Georg-Johann Lay , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: Re: Cleaning up expand optabs code References: <4D825EF5.1010307@redhat.com> <87wrju28hn.fsf@firetop.home> <4D87A69B.90704@redhat.com> <4D88E10A.8080005@redhat.com> <4D8B32A9.9050309@linux.vnet.ibm.com> <4D8C8D81.5080103@gjlay.de> <4D8CCE3D.7010100@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2011-03/txt/msg01791.txt.bz2 On 03/25/2011 10:51 AM, Richard Sandiford wrote: > Thanks. I think it needs to be s/!= 4/>= 6/ though, so that > match_scratches still work when 6 operands really are passed in. For the record, I audited all setmem and movmem patterns. There are is only one that uses 6 operands: i386. There are two that use 4 operands, but have 1 scratch: avr, pdp11. All the rest have exactly 4 operands. I'll leave the test as == 6 for now. > Fully agreed on the optional args thing. Or maybe insn_data should > have a separate "num_args" field. This is sounds like a good thing. It's probably worth doing some checking in some genfoo (opinit?) that the named patterns have exactly the number of operands expected. r~