From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25925 invoked by alias); 11 Aug 2011 08:12:54 -0000 Received: (qmail 25915 invoked by uid 22791); 11 Aug 2011 08:12:52 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yw0-f47.google.com (HELO mail-yw0-f47.google.com) (209.85.213.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Aug 2011 08:12:36 +0000 Received: by ywe9 with SMTP id 9so1233346ywe.20 for ; Thu, 11 Aug 2011 01:12:36 -0700 (PDT) Received: by 10.236.76.135 with SMTP id b7mr8199197yhe.56.1313050356086; Thu, 11 Aug 2011 01:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.41.16 with HTTP; Thu, 11 Aug 2011 01:11:56 -0700 (PDT) In-Reply-To: <4E431BD8.8060705@redhat.com> References: <4E431BD8.8060705@redhat.com> From: "Paulo J. Matos" Date: Thu, 11 Aug 2011 08:12:00 -0000 Message-ID: Subject: Re: Move insn out of the way To: Vladimir Makarov Cc: gcc@gcc.gnu.org, Richard Guenther Content-Type: text/plain; charset=UTF-8 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/msg00214.txt.bz2 On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov wro= te: > I can not reproduce the problem.=C2=A0 It would be nice to give all info = (the > code without includes and all options).=C2=A0 In this case I could have m= ore info > to say more definitely about the reason of the problem in IRA. > One of the issue with these problems of mine is that they are tied to my backend, but not always. I think I managed to reproduce a similar result in the avr backend using GCC4.6.1 test.c: long long x; _Bool mask (long long a) { return (x & a) =3D=3D a; } $ avr-cc1 -Os test.c This generates the following assembler: mask: push r13 push r14 push r15 push r16 push r17 /* prologue: function */ /* frame size =3D 0 */ /* stack size =3D 5 */ .L__stack_usage =3D 5 lds r14,x and r14,r18 lds r15,x+1 and r15,r19 lds r16,x+2 and r16,r20 lds r17,x+3 and r17,r21 lds r27,x+4 and r27,r22 lds r26,x+5 and r26,r23 lds r31,x+6 and r31,r24 lds r30,x+7 and r30,r25 clr r13 inc r13 cp r14,r18 brne .L3 cp r15,r19 brne .L3 cp r16,r20 brne .L3 cp r17,r21 brne .L3 cp r27,r22 brne .L3 cp r26,r23 brne .L3 cp r31,r24 brne .L3 cpse r30,r25 .L3: clr r13 .L2: mov r24,r13 /* epilogue start */ pop r17 pop r16 pop r15 pop r14 pop r13 ret .size mask, .-mask .comm x,8,1 I can't tell how good or bad this assembler is but I note a couple of similarities with my backends assembler output: - It doesn't do if-conversion like Richard suggested. So (x & a) =3D=3D a is not converted to ((xl & al) ^ al) | ((xh & ah) ^ ah) =3D=3D 0. - The assignment of r13 to 1 is done as 'clr r13; inc r13' _before_ the jum= ps. The only assignment to r13 is as in my case after the jumps as 'clr 13' to set up the return value. I am not sure if this situation causes a lot of register pressure, however I think it doesn't in avr but it does in my backend. AVR has 32 registers to play with, mine can only deal with 3 in the destination operand position. --=20 PMatos