From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11000 invoked by alias); 11 Aug 2011 14:27:27 -0000 Received: (qmail 10989 invoked by uid 22791); 11 Aug 2011 14:27:26 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Aug 2011 14:27:06 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7BER61J006679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2011 10:27:06 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p7BER5a1027914; Thu, 11 Aug 2011 10:27:05 -0400 Received: from localhost.localdomain (ovpn-113-25.phx2.redhat.com [10.3.113.25]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p7BER324008178; Thu, 11 Aug 2011 10:27:03 -0400 Message-ID: <4E43E6BC.90003@redhat.com> Date: Thu, 11 Aug 2011 14:27:00 -0000 From: Vladimir Makarov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Richard Guenther CC: "Paulo J. Matos" , gcc@gcc.gnu.org Subject: Re: Move insn out of the way References: <4E431BD8.8060705@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00219.txt.bz2 On 08/11/2011 04:49 AM, Richard Guenther wrote: > On Thu, Aug 11, 2011 at 10:11 AM, Paulo J. Matos wrote: >> On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov wrote: >>> I can not reproduce the problem. It would be nice to give all info (the >>> code without includes and all options). In this case I could have more 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) == 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 = 0 */ >> /* stack size = 5 */ >> .L__stack_usage = 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) == a >> is not converted to ((xl& al) ^ al) | ((xh& ah) ^ ah) == 0. >> - The assignment of r13 to 1 is done as 'clr r13; inc r13' _before_ the jumps. >> >> 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? > Yes, that is mostly correct. The first could be done by -fweb (if the live range where the pseudo is equal to the constant is disjoint). The first could be done also by Jeff Law's project which can provide splitting not only on the border of loops. Some problems might be solved even in LRA (a new project I am working on) which would spill the pseudo assigned to constant, assign the hard registers to conflicting non-reload pseudos (spilled in IRA) and inherit the hard register for the reload pseudos of the spilled pseudo (if insns can not use the constant directly) achieving this way live range splitting for the spilled pseudo. Reload pass can not do this because it does not assign hard registers to pseudos spilled in IRA when a hard register is freed by spilling a conflicting pseudo for reloads. Actually the same problem exists in the old RA. IRA is different from it mostly by: o live range splitting at the most important program points (loop borders) o better coloring o better choosing hard registers o better coalescing o better communication with reload pass