From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23140 invoked by alias); 14 Mar 2008 10:11:42 -0000 Received: (qmail 23123 invoked by uid 22791); 14 Mar 2008 10:11:41 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Mar 2008 10:11:15 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m2EABDZh026597; Fri, 14 Mar 2008 06:11:13 -0400 Received: from zebedee.pink (vpn-14-34.rdu.redhat.com [10.11.14.34]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m2EABCeW026799; Fri, 14 Mar 2008 06:11:12 -0400 Message-ID: <47DA4F40.7060801@redhat.com> Date: Fri, 14 Mar 2008 10:11:00 -0000 From: Andrew Haley User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: Ian Lance Taylor CC: Clem Taylor , gcc-help@gcc.gnu.org Subject: Re: workaround for "error: more than 30 operands in 'asm'"? References: <47D8F7B5.5030306@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-03/txt/msg00130.txt.bz2 Ian Lance Taylor wrote: > Andrew Haley writes: > >> Ian Lance Taylor wrote: >>> "Clem Taylor" writes: >>> >>>> I'm working on taking PowerPC VMX code that uses altivec intrinsics >>>> and rescheduling it with inline assembly. gcc is making some fairly >>>> bad scheduling choices in with the code, resulting in code that is >>>> running 4x slower then I was hoping for. I have a simplified version >>>> working, but with the real version gcc is failing with: "error: more >>>> than 30 operands in 'asm'". The code is using 28 vector registers and >>>> 6 serial registers. >>>> >>>> The code is a mixture of setup code in C and only the inner loop is in >>>> assembly, so it wouldn't be convenient to write this directly in >>>> assembly. Also, because the code is highly pipelined (to overcome the >>>> latency of the VMX floating point unit) it is a mess to split this up >>>> into multiple asm() statements. Beyond recompiling gcc with a larger >>>> operand count, is there a workaround for this problem? >>> Use fewer operands? Otherwise, no. It's a hard limit in gcc. >>> >>> Since you mention the number of registers you are using, note that >>> that only matters if they are inputs or outputs. If you need a >>> temporary register, just pick one, and add it the clobber list. But >>> if you really have that many inputs and outputs, then you are stuck. >> Isn't this trivially fixed by changing: >> >> /* Allow at least 30 operands for the sake of asm constructs. */ >> /* ??? We *really* ought to reorganize things such that there >> is no fixed upper bound. */ >> max_recog_operands = 29; /* We will add 1 later. */ >> max_dup_operands = 1; >> >> in genconfig.c ? > > Yes. Sorry for being confusing, I was answering the question "beyond > recompiling gcc...." I wonder if we could do something more sensible than simply using the constant 30. Perhaps some function of FIRST_PSEUDO_REGISTER, like FIRST_PSEUDO_REGISTER+20, or FIRST_PSEUDO_REGISTER*2 or even MAX (FIRST_PSEUDO_REGISTER, 29). This would at least solve the problem here. Andrew.