From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-117720-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 5184 invoked by alias); 26 Jul 2005 01:10:14 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 5170 invoked by uid 22791); 26 Jul 2005 01:10:09 -0000
Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 26 Jul 2005 01:10:09 +0000
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
	by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j6Q1A7aR015501
	for <gcc@gcc.gnu.org>; Mon, 25 Jul 2005 18:10:07 -0700 (PDT)
Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.3.17) with ESMTP id <T725b98ba24118064e137c@mailgate1.apple.com> for <gcc@gcc.gnu.org>;
 Mon, 25 Jul 2005 18:10:07 -0700
Received: from [17.201.20.185] (johada5.apple.com [17.201.20.185])
	by relay3.apple.com (8.12.11/8.12.11) with ESMTP id j6Q1A5aS017506;
	Mon, 25 Jul 2005 18:10:06 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0f330882304cdfaf28ef9c2b1360380c@apple.com>
Content-Transfer-Encoding: 7bit
Cc: Dale Johannesen <dalej@apple.com>
From: Dale Johannesen <dalej@apple.com>
Subject: rfa (x86):  387<=>sse moves
Date: Tue, 26 Jul 2005 01:10:00 -0000
To: GCC Development <gcc@gcc.gnu.org>
X-SW-Source: 2005-07/txt/msg01084.txt.bz2

With -march=pentium4 -mfpmath=sse -O2, we get an extra move for code 
like

     double d = atof(foo);
     int i = d;

         call    atof
         fstpl   -8(%ebp)
         movsd   -8(%ebp), %xmm0
         cvttsd2si       %xmm0, %eax

(This is Linux, Darwin is similar.)  I think the difficulty is that for

(set (reg/v:DF 58 [ d ]) (reg:DF 8 st)) 64 {*movdf_nointeger}

regclass decides SSE_REGS is a zero-cost choice for 58.  Which looks
wrong, as that requires a store and load from memory.  In fact, memory 
is
the cheapest overall choice for 58 (taking its use into account also), 
and
gcc will figure that out correctly if a more reasonable assessment is 
given
to SSE_REGS.  The immediate cause is the #Y's in the constraint:

                         "=f#Y,m  ,f#Y,*r  ,o  ,Y*x#f,Y*x#f,Y*x#f  ,m    
"

and there's probably a simple fix, but it eludes me.  Advice?  Thanks.