From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-293835-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 18129 invoked by alias); 7 Jun 2011 14:03:01 -0000
Received: (qmail 18117 invoked by uid 22791); 7 Jun 2011 14:03:00 -0000
X-SWARE-Spam-Status: No, hits=-2.2 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,TW_ZJ
X-Spam-Check-By: sourceware.org
Received: from mail-pz0-f47.google.com (HELO mail-pz0-f47.google.com) (209.85.210.47)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Jun 2011 14:02:46 +0000
Received: by pzk36 with SMTP id 36so2645138pzk.20        for <gcc-patches@gcc.gnu.org>; Tue, 07 Jun 2011 07:02:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.245.16 with SMTP id s16mr25286wfh.139.1307455365498; Tue, 07 Jun 2011 07:02:45 -0700 (PDT)
Received: by 10.142.78.4 with HTTP; Tue, 7 Jun 2011 07:02:45 -0700 (PDT)
In-Reply-To: <BANLkTin01-YvDPXskejB8TcX59VGHAMcxw@mail.gmail.com>
References: <BANLkTinDbrWcYi6x1zDsaC34M1tA1iC1oQ@mail.gmail.com>	<BANLkTin01-YvDPXskejB8TcX59VGHAMcxw@mail.gmail.com>
Date: Tue, 07 Jun 2011 14:03:00 -0000
Message-ID: <BANLkTimozGYneD-6xQn7qo1LYo82pEA26Q@mail.gmail.com>
Subject: Re: [PATCH, i386]: Remaining FP moves cleanups
From: Uros Bizjak <ubizjak@gmail.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-06/txt/msg00520.txt.bz2

On Tue, Jun 7, 2011 at 3:42 PM, H.J. Lu <hjl.tools@gmail.com> wrote:

>> 2011-06-05 =A0Uros Bizjak =A0<ubizjak@gmail.com>
>>
>> =A0 =A0 =A0 =A0* config/i386/i386.md (*movdf_internal_rex64) <case 8,9,1=
0>:
>> =A0 =A0 =A0 =A0Remove MODE_TI handling. =A0Remove SSE1 handling in attri=
bute "mode"
>> =A0 =A0 =A0 =A0calculation.
>> =A0 =A0 =A0 =A0(*movdf_internal_rex64) <case 6,7,8>: Remove MODE_TI hand=
ling.
>> =A0 =A0 =A0 =A0Simplify MODE_V1DF and MODE_V2SF handling.
>> =A0 =A0 =A0 =A0(*movsf_internal): Remove x constraint from operand 1 alt=
ernative 7.
>> =A0 =A0 =A0 =A0Simplify MODE_SF handling.
>>
>> Patch was bootstrapped and regression tested on x86_64-pc-linux-gnuj
>> {,-m32} AVX target. Committed to mainline SVN.
>>
>
> Hi Uros,
>
> The new *movsf_internal patter has
>
> =A0[(set (match_operand:SF 0 "nonimmediate_operand"
> =A0 =A0 =A0 =A0 =A0"=3Df,m,f,?r ,?m,x,x,x,m,!*y,!m,!*y,?Yi,?r,!*Ym,!r")
> =A0 =A0 =A0 =A0(match_operand:SF 1 "general_operand"
> =A0 =A0 =A0 =A0 =A0"fm,f,G,rmF,Fr,C,x,m,x,m =A0,*y,*y ,r =A0,Yi,r =A0 ,*Y=
m"))]
> ...
> =A0 =A0case 7:
> =A0 =A0case 8:
> =A0 =A0 =A0if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
> =A0 =A0 =A0 =A0return "vmovss\t{%1, %0, %0|%0, %0, %1}";
> =A0 =A0 =A0return "%vmovss\t{%1, %0|%0, %1}";
>
> Since 7 is store and 8 is load,
>
> if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
>
> will always be false. =A0Should we remove it?

No, because it also handles fallthru from case 6.

OTOH, you are right, this statement can be moved to case 6, without
the check for registers.

Thanks,
Uros.