From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30076 invoked by alias); 11 Aug 2011 08:49:43 -0000 Received: (qmail 30066 invoked by uid 22791); 11 Aug 2011 08:49:41 -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-gx0-f175.google.com (HELO mail-gx0-f175.google.com) (209.85.161.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Aug 2011 08:49:21 +0000 Received: by gxk3 with SMTP id 3so15859gxk.20 for ; Thu, 11 Aug 2011 01:49:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.54.7 with SMTP id c7mr343418yba.250.1313052560505; Thu, 11 Aug 2011 01:49:20 -0700 (PDT) Received: by 10.150.219.17 with HTTP; Thu, 11 Aug 2011 01:49:20 -0700 (PDT) In-Reply-To: References: <4E431BD8.8060705@redhat.com> Date: Thu, 11 Aug 2011 08:49:00 -0000 Message-ID: Subject: Re: Move insn out of the way From: Richard Guenther To: "Paulo J. Matos" Cc: Vladimir Makarov , 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/msg00215.txt.bz2 On Thu, Aug 11, 2011 at 10:11 AM, Paulo J. Matos wr= ote: > On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov w= rote: >> I can not reproduce the problem.=A0 It would be nice to give all info (t= he >> code without includes and all options).=A0 In this case I could have mor= e 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) > { > =A0return (x & a) =3D=3D a; > } > > $ avr-cc1 -Os test.c > > This generates the following assembler: > mask: > =A0 =A0 =A0 =A0push r13 > =A0 =A0 =A0 =A0push r14 > =A0 =A0 =A0 =A0push r15 > =A0 =A0 =A0 =A0push r16 > =A0 =A0 =A0 =A0push r17 > /* prologue: function */ > /* frame size =3D 0 */ > /* stack size =3D 5 */ > .L__stack_usage =3D 5 > =A0 =A0 =A0 =A0lds r14,x > =A0 =A0 =A0 =A0and r14,r18 > =A0 =A0 =A0 =A0lds r15,x+1 > =A0 =A0 =A0 =A0and r15,r19 > =A0 =A0 =A0 =A0lds r16,x+2 > =A0 =A0 =A0 =A0and r16,r20 > =A0 =A0 =A0 =A0lds r17,x+3 > =A0 =A0 =A0 =A0and r17,r21 > =A0 =A0 =A0 =A0lds r27,x+4 > =A0 =A0 =A0 =A0and r27,r22 > =A0 =A0 =A0 =A0lds r26,x+5 > =A0 =A0 =A0 =A0and r26,r23 > =A0 =A0 =A0 =A0lds r31,x+6 > =A0 =A0 =A0 =A0and r31,r24 > =A0 =A0 =A0 =A0lds r30,x+7 > =A0 =A0 =A0 =A0and r30,r25 > =A0 =A0 =A0 =A0clr r13 > =A0 =A0 =A0 =A0inc r13 > =A0 =A0 =A0 =A0cp r14,r18 > =A0 =A0 =A0 =A0brne .L3 > =A0 =A0 =A0 =A0cp r15,r19 > =A0 =A0 =A0 =A0brne .L3 > =A0 =A0 =A0 =A0cp r16,r20 > =A0 =A0 =A0 =A0brne .L3 > =A0 =A0 =A0 =A0cp r17,r21 > =A0 =A0 =A0 =A0brne .L3 > =A0 =A0 =A0 =A0cp r27,r22 > =A0 =A0 =A0 =A0brne .L3 > =A0 =A0 =A0 =A0cp r26,r23 > =A0 =A0 =A0 =A0brne .L3 > =A0 =A0 =A0 =A0cp r31,r24 > =A0 =A0 =A0 =A0brne .L3 > =A0 =A0 =A0 =A0cpse r30,r25 > .L3: > =A0 =A0 =A0 =A0clr r13 > .L2: > =A0 =A0 =A0 =A0mov r24,r13 > /* epilogue start */ > =A0 =A0 =A0 =A0pop r17 > =A0 =A0 =A0 =A0pop r16 > =A0 =A0 =A0 =A0pop r15 > =A0 =A0 =A0 =A0pop r14 > =A0 =A0 =A0 =A0pop r13 > =A0 =A0 =A0 =A0ret > =A0 =A0 =A0 =A0.size =A0 mask, .-mask > =A0 =A0 =A0 =A0.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 j= umps. > > 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. What I was expecting IRA to do is 1) split live-range at kills, thus if a constant is assigned to a pseudo then the constant has its own live-range 2) pseudos that are equal to a constant are assigned hard registers last if re-materializing them during reload is cheaper than spilling them I suspect that 1) is not happening, I hope that 2) would happen already. Correct? Richard. > -- > PMatos >