From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "az33egw02.freescale.net", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 5AD7EDDF88 for ; Thu, 22 May 2008 06:31:43 +1000 (EST) Date: Wed, 21 May 2008 13:25:52 -0700 (PDT) From: Trent Piepho To: Andreas Schwab Subject: Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code In-Reply-To: Message-ID: References: <1211316025-29069-1-git-send-email-tpiepho@freescale.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Scott Wood , linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 21 May 2008, Andreas Schwab wrote: > Trent Piepho writes: >> On Wed, 21 May 2008, Andreas Schwab wrote: >>> Trent Piepho writes: >>>> It's the _le versions that have a problem, since we can't get gcc to just use >>>> the register indexed mode. It seems like an obvious thing to have a >>>> constraint for, but I guess there weren't enough instructions that only come >>>> in 'x' versions to bother with it. There is a 'Z' constraint, "Memory operand >>>> that is an indexed or indirect from a register", but I tried it and it can use >>>> both "rb,ri" and "disp(rb)" forms. Actually, I'm not sure how 'Z' is any >>>> different than "m"? >>> >>> 'Z' will never emit a non-zero constant displacement. >> >> It's too bad gas doesn't appear to be smart enough to turn: >> stwbrx 0, 0(3) -or- stwbr 0, 0(3) > > Use the %y modifier when substituting the operand. Of course, the undocumented y modifier! "Print AltiVec or SPE memory operand" Why didn't I think of that? That appears to work. I can get gcc to to emit 0,reg and reg,reg but not disp(reg). It won't try to use an "update" address either, though it will with an "m" constraint. But, gcc 4.0.2 can't handle the 'Z' constraint. It looks like it's not supported. Other than this, I can build a kernel with 4.0.2 that appears to work. Is it ok to break compatibility with 4.0.2, or should I put in a gcc version check?