From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2173 invoked by alias); 25 Mar 2011 17:51:51 -0000 Received: (qmail 2142 invoked by uid 22791); 25 Mar 2011 17:51:48 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Mar 2011 17:51:40 +0000 Received: by wwf26 with SMTP id 26so946804wwf.8 for ; Fri, 25 Mar 2011 10:51:39 -0700 (PDT) Received: by 10.216.52.78 with SMTP id d56mr986079wec.44.1301075499540; Fri, 25 Mar 2011 10:51:39 -0700 (PDT) Received: from richards-thinkpad (gbibp9ph1--blueice2n1.emea.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id s40sm422639weq.28.2011.03.25.10.51.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Mar 2011 10:51:37 -0700 (PDT) From: Richard Sandiford To: Richard Henderson Mail-Followup-To: Richard Henderson ,Georg-Johann Lay , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Cc: Georg-Johann Lay , gcc-patches@gcc.gnu.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> Date: Fri, 25 Mar 2011 17:56:00 -0000 In-Reply-To: <4D8CCE3D.7010100@redhat.com> (Richard Henderson's message of "Fri, 25 Mar 2011 10:17:49 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg01780.txt.bz2 Richard Henderson writes: > This is due to a miscommunication between the middle-end and the backend > about how many arguments the setmemhi pattern takes. > > (define_expand "setmemhi" > [(parallel [(set (match_operand:BLK 0 "memory_operand" "") > (match_operand 2 "const_int_operand" "")) > (use (match_operand:HI 1 "const_int_operand" "")) > (use (match_operand:HI 3 "const_int_operand" "n")) > (clobber (match_scratch:HI 4 "")) > (clobber (match_dup 5))])] > > The match_scratch is counted in .n_operands, which makes the count of > operands not equal 4, so we assume 6 operands are necessary. We can > fix this for the special case of avr by only assuming 6 operands when > there are in fact 6 operands, but of course this could fail just as > easily if there were two scratches. > > All of which suggests that optional arguments to a named optab is a > mistake that ought to be rectified. > > I plan to commit the following after bootstrap and check. Thanks. I think it needs to be s/!= 4/>= 6/ though, so that match_scratches still work when 6 operands really are passed in. Fully agreed on the optional args thing. Or maybe insn_data should have a separate "num_args" field. Richard