From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11207 invoked by alias); 10 Aug 2011 13:46:55 -0000 Received: (qmail 11198 invoked by uid 22791); 10 Aug 2011 13:46:54 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Aug 2011 13:46:40 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qr97F-0007vL-Cb for gcc@gcc.gnu.org; Wed, 10 Aug 2011 15:46:37 +0200 Received: from 193.128.72.68 ([193.128.72.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Aug 2011 15:46:37 +0200 Received: from paulo by 193.128.72.68 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Aug 2011 15:46:37 +0200 To: gcc@gcc.gnu.org From: "Paulo J. Matos" Subject: Re: Move insn out of the way Date: Wed, 10 Aug 2011 13:46:00 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 In-Reply-To: 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/msg00205.txt.bz2 On 10/08/11 12:40, Richard Guenther wrote: > > On x86 we expand the code to ((xl& al) ^ al) | ((xh& ah) ^ ah) == 0 > which is then if-converted. Modified testcase: > > long long x; > _Bool __attribute__((regparm(2))) mask (long long a) > { > return (x& a) == a; > } > > on i?86 gets you > > mask: > .LFB0: > .cfi_startproc > pushl %ebx > .cfi_def_cfa_offset 8 > .cfi_offset 3, -8 > movl %eax, %ebx > andl x, %ebx > movl %edx, %ecx > andl x+4, %ecx > xorl %ebx, %eax > xorl %ecx, %edx > orl %edx, %eax > sete %al > popl %ebx > .cfi_restore 3 > .cfi_def_cfa_offset 4 > 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 pass before expand shows the original (x & a) == 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 this 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 implemented to do if-conversion on i386 needs to be implemented also on my backend. Can you point me to the code on i386 so I can take a look at it? Cheers, -- PMatos