From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2413 invoked by alias); 12 Aug 2011 14:22:09 -0000 Received: (qmail 2395 invoked by uid 22791); 12 Aug 2011 14:22:06 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SARE_LWSHORTT,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; Fri, 12 Aug 2011 14:21:47 +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 p7CELkYY014058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Aug 2011 10:21:46 -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 p7CELkQt006778; Fri, 12 Aug 2011 10:21:46 -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 p7CELiJP006746; Fri, 12 Aug 2011 10:21:45 -0400 Message-ID: <4E4536FD.4070705@redhat.com> Date: Fri, 12 Aug 2011 14:22: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: "Paulo J. Matos" CC: Richard Guenther , gcc@gcc.gnu.org Subject: Re: Move insn out of the way References: <4E431BD8.8060705@redhat.com> <4E43E6BC.90003@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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/msg00250.txt.bz2 On 08/12/2011 06:00 AM, Paulo J. Matos wrote: > On Thu, Aug 11, 2011 at 3:27 PM, Vladimir Makarov wrote: >> 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. >> > I was thinking that one possible solution in the short term would be > to add a new pass just before IRA which does constant assignment > moves. So, an insn where a register which is assigned a constant can > be moved as much as possible to the place right before the use of the > register or if there's no use of the register inside the current BB, > it can be moved as the last instruction of the BB. > > What do you think about this? Would this work? I know it's not very > general, however, it's useful at least for my backend to get this > right as soon as possible due to several size test failures we have > which are a consequence of this problem. Sorry, Paulo. I don't think it is a good idea to have such a general pass. A constant depending on its value could be prohibited to be used in insn. Moving assignment to the constant most probably worsens insn schedule on targets where the 1st insn scheduling is a default. But moving the pass before 1st insn scheduling could work if register pressure sensitive insn scheduling is used. Still it is too specialized pass. I think register pressure relief as it is described in Simpson's thesis would be a more general approach. But to be honest, I think, the best solution would be in RA because it is dealing with insn constraints and costs. I'll think about solving this problem in RA.