From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-280950-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21957 invoked by alias); 14 Dec 2010 02:17:06 -0000
Received: (qmail 21947 invoked by uid 22791); 14 Dec 2010 02:17:05 -0000
X-SWARE-Spam-Status: No, hits=-2.3 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW
X-Spam-Check-By: sourceware.org
Received: from mail-qw0-f51.google.com (HELO mail-qw0-f51.google.com) (209.85.216.51)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Dec 2010 02:17:00 +0000
Received: by qwj8 with SMTP id 8so190051qwj.10        for <gcc-patches@gcc.gnu.org>; Mon, 13 Dec 2010 18:16:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.63.228 with SMTP id c36mr4790907qai.17.1292293018383; Mon, 13 Dec 2010 18:16:58 -0800 (PST)
Received: by 10.220.62.9 with HTTP; Mon, 13 Dec 2010 18:16:58 -0800 (PST)
In-Reply-To: <4D06CB32.70304@codesourcery.com>
References: <4D010FFC.6040805@codesourcery.com>	<AANLkTin=7NEnC6RBh1c9W2BoKsMQHC3GCJY0tfKg0iDr@mail.gmail.com>	<4D06CB32.70304@codesourcery.com>
Date: Tue, 14 Dec 2010 04:20:00 -0000
Message-ID: <AANLkTi=XN1TyOZJ8=WCbo+a=mVAReds3rMC5swTH1OWa@mail.gmail.com>
Subject: Re: [patch, combine] Bit-field insertion optimization #2
From: Andrew Pinski <pinskia@gmail.com>
To: Chung-Lin Tang <cltang@codesourcery.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
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: 2010-12/txt/msg01048.txt.bz2

On Mon, Dec 13, 2010 at 5:41 PM, Chung-Lin Tang <cltang@codesourcery.com> w=
rote:
> On 2010/12/14 07:06, Andrew Pinski wrote:
>> This patch is broken when we have:
>> (insn 8 7 14 2 ins-23.c:25 (set (zero_extract:SI (reg:SI 195 [ a ])
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (const_int 8 [0x8])
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (const_int 12 [0xc]))
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (reg:SI 196)) 214 {insvsi} (expr_list:REG_EQ=
UAL (const_int -1
>> [0xffffffffffffffff])
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (nil)))
>>
>> It does the correct thing of replacing it with:
>> (set (reg:SI 195 [ a ])
>> =C2=A0 =C2=A0 (ior:SI (reg:SI 4 $4 [ a ])
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (const_int 1044480 [0xff000])))
>> But then it does remove the reg_equal from the instruction which
>> causes us to get:
>> (set (reg/i:DI 2 $2)
>> =C2=A0 =C2=A0 (const_int -1 [0xffffffffffffffff]))
>
> Hi Andrew, thanks for testing and finding this. Do you have a testcase I
> can use?


It is hard to reproduce on the trunk as I have some changes in the
mips back-end.  Though we might get the same RTL doing something like:
struct a
{
  long long a:32;
  long long b:8;
  long long c:24;
};
struct a f(struct a a)
{
  a.b=3D-1;
  return a;
}

Thanks,
Andrew Pinski