From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16862 invoked by alias); 10 Aug 2011 13:51:57 -0000 Received: (qmail 16851 invoked by uid 22791); 10 Aug 2011 13:51:56 -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-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Aug 2011 13:51:42 +0000 Received: by yxi19 with SMTP id 19so693858yxi.20 for ; Wed, 10 Aug 2011 06:51:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.193.21 with SMTP id q21mr256227ybf.136.1312984302147; Wed, 10 Aug 2011 06:51:42 -0700 (PDT) Received: by 10.150.219.17 with HTTP; Wed, 10 Aug 2011 06:51:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Aug 2011 13:51:00 -0000 Message-ID: Subject: Re: Move insn out of the way From: Richard Guenther To: "Paulo J. Matos" Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg00206.txt.bz2 On Wed, Aug 10, 2011 at 3:46 PM, Paulo J. Matos wro= te: > On 10/08/11 12:40, Richard Guenther wrote: >> >> On x86 we expand the code to ((xl& =A0al) ^ al) | ((xh& =A0ah) ^ ah) =3D= =3D 0 >> which is then if-converted. =A0Modified testcase: >> >> long long x; >> _Bool __attribute__((regparm(2))) mask (long long a) >> { >> =A0 return (x& =A0a) =3D=3D a; >> } >> >> on i?86 gets you >> >> mask: >> .LFB0: >> =A0 =A0 =A0 =A0 .cfi_startproc >> =A0 =A0 =A0 =A0 pushl =A0 %ebx >> =A0 =A0 =A0 =A0 .cfi_def_cfa_offset 8 >> =A0 =A0 =A0 =A0 .cfi_offset 3, -8 >> =A0 =A0 =A0 =A0 movl =A0 =A0%eax, %ebx >> =A0 =A0 =A0 =A0 andl =A0 =A0x, %ebx >> =A0 =A0 =A0 =A0 movl =A0 =A0%edx, %ecx >> =A0 =A0 =A0 =A0 andl =A0 =A0x+4, %ecx >> =A0 =A0 =A0 =A0 xorl =A0 =A0%ebx, %eax >> =A0 =A0 =A0 =A0 xorl =A0 =A0%ecx, %edx >> =A0 =A0 =A0 =A0 orl =A0 =A0 %edx, %eax >> =A0 =A0 =A0 =A0 sete =A0 =A0%al >> =A0 =A0 =A0 =A0 popl =A0 =A0%ebx >> =A0 =A0 =A0 =A0 .cfi_restore 3 >> =A0 =A0 =A0 =A0 .cfi_def_cfa_offset 4 >> =A0 =A0 =A0 =A0 ret >> >> so I wonder if you should investigate why the xor variant doesn't trigger >> for you? > > I can reproduce this result in GCC 4.6.1 for x86. > I can't understand what you mean by this though. From inspecting the logs= it > seems that the if-conversion is done manually at expand time. The final p= ass > before expand shows the original (x & a) =3D=3D a, however, after expand = the rtl > already contains xor, ior, etc. So I guess I would need to do something > similar in my backend. I can't however, find in the i386(.md|.c) where th= is > is actually happening. > >> On i?86 if-conversion probably solves your specific issue, >> but I guess the initial expansion is where you could improve placement >> of the 1 (after all, the 0 is after the jumps). >> > > This is happening on my own backend so I guess anything that is implement= ed > to do if-conversion on i386 needs to be implemented also on my backend. C= an > you point me to the code on i386 so I can take a look at it? I think it's all happening in generic code via do_store_flag. Richard. > Cheers, > > -- > PMatos > >