From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17224 invoked by alias); 18 Nov 2004 01:19:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 17162 invoked from network); 18 Nov 2004 01:19:23 -0000 Received: from unknown (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org with SMTP; 18 Nov 2004 01:19:23 -0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1CUaxB-0000BQ-K0; Wed, 17 Nov 2004 17:19:17 -0800 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32677-10; Wed, 17 Nov 2004 17:19:17 -0800 (PST) Received: from egret.hq.tensilica.com ([192.168.11.80] ident=[1/vBV9vnn/Z6yYs+TfCMq8kN6QB+kggH]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1CUaxB-0000BL-Be; Wed, 17 Nov 2004 17:19:17 -0800 Received: from tensilica.com (wintergreen.vpn.tensilica.com [172.16.12.1]) by egret.hq.tensilica.com (8.11.6/8.11.6) with ESMTP id iAI1JGw07919; Wed, 17 Nov 2004 17:19:16 -0800 Message-ID: <419BF869.2060807@tensilica.com> Date: Thu, 18 Nov 2004 02:43:00 -0000 From: Bob Wilson Organization: Tensilica, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Alan Modra CC: Richard Henderson , gcc@gcc.gnu.org Subject: Re: [cft] subreg validation round 2 References: <20041117184009.GA12257@redhat.com> <419BA411.5090801@tensilica.com> <20041117194553.GA12418@redhat.com> <20041118005308.GC17083@bubble.modra.org> In-Reply-To: <20041118005308.GC17083@bubble.modra.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at hq.tensilica.com X-SW-Source: 2004-11/txt/msg00603.txt.bz2 Alan Modra wrote: > On Wed, Nov 17, 2004 at 11:45:53AM -0800, Richard Henderson wrote: > >>On Wed, Nov 17, 2004 at 11:18:41AM -0800, Bob Wilson wrote: >> >>>If so, should I change FUNCTION_ARG code to avoid >>>returning a BLKmode reg? Should I wrap the REG in a PARALLEL? >> >>Presumably you didn't just return the SImode reg in the first place >>because you want the three bytes in the high part of the register? >>Then, yes, a PARALLEL should do. > > > Or define a suitable BLOCK_REG_PADDING. At least, that used to work.. I'm looking into it, but from a quick check of various other ports, I'm surprised that more of them aren't breaking. (Or maybe they are....) Many of the FUNCTION_ARG implementations create a REG with whatever mode is specified as an argument to FUNCTION_ARG, which is what the Xtensa code does. I'm not doing anything special here. The "smaller than a word struct argument" case that causes the ICE is actually the easiest to handle. Ignoring the padding issue, a single SImode REG will work. For a struct bigger than a word, I guess a PARALLEL is required to specify each consecutive register separately (at least in the general case where there is no mode of the right size). I can see why it should be that way, but it was so much easier to just specify the first register with BLKmode.... Thanks for the suggestions. --Bob