From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12244 invoked by alias); 28 Jun 2010 23:00:43 -0000 Received: (qmail 12233 invoked by uid 22791); 28 Jun 2010 23:00:42 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_XM,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; Mon, 28 Jun 2010 23:00:38 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5SN0b78032721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Jun 2010 19:00:37 -0400 Received: from stone.twiddle.home (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o5SN0aTB030725 for ; Mon, 28 Jun 2010 19:00:36 -0400 Message-ID: <4C29297F.9090402@redhat.com> Date: Tue, 29 Jun 2010 00:27:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5 MIME-Version: 1.0 To: gcc-patches@gcc.gnu.org Subject: Re: A few simple DImode improvements References: <4C2549D4.10608@codesourcery.com> <201006272336.56278.ebotcazou@adacore.com> <4C28EB04.6040106@redhat.com> In-Reply-To: <4C28EB04.6040106@redhat.com> 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: 2010-06/txt/msg02961.txt.bz2 On 06/28/2010 11:33 AM, Jeff Law wrote: > On 06/28/10 12:05, Ian Lance Taylor wrote: >> I don't know >> whether this a concern with IRA; can IRA allocate a DImode pseudo to a >> floating point register if there are SImode SUBREGs of it? The old >> register allocator wouldn't, and you could wind up with a bunch of >> reloads. >> > I would expect that unless the target explicitly forbids such an > allocation via CANNOT_CHANGE_MODE_CLASS, then it ought to work. In > fact, this is a normal code generation situation for the PA family to > support xmpyu -- if it had been broken I suspect we would have heard > about it by now as anything doing an integer multiply would suddenly be > using libcalls instead of xmpyu. CANNOT_CHANGE_MODE_CLASS is the normal state of affairs for several ports doing int<->fp conversion. Where DImode is the only valid integer mode, and the single-precision load instruction does some bit swizzling (to place the SFmode value into register format) so that 32-bit integer values cannot be loaded or manipulated. This is true of some ppc variants and alpha, at least. As such, this is sort-of a non-answer, Jeff. r~