From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28700 invoked by alias); 19 Apr 2013 13:37:39 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 28691 invoked by uid 89); 19 Apr 2013 13:37:38 -0000 X-Spam-SWARE-Status: No, score=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_EG,TW_GC autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 19 Apr 2013 13:37:37 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3JDba2G017812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Apr 2013 09:37:36 -0400 Received: from Mair.local (vpn-48-120.rdu2.redhat.com [10.10.48.120]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r3JDbY3V008785; Fri, 19 Apr 2013 09:37:35 -0400 Message-ID: <5171489E.4020705@redhat.com> Date: Fri, 19 Apr 2013 16:25:00 -0000 From: Vladimir Makarov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Richard Biener CC: Steven Bosscher , Jeff Law , GCC Patches Subject: Re: [PATCH, PR 10474] Shedule pass_cprop_hardreg before pass_thread_prologue_and_epilogue References: <20130417154935.GC3656@virgil.suse> <516EED6F.9030007@redhat.com> <20130418220949.GA3859@alvy.suse.cz> <20130418230811.GB3859@alvy.suse.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg01148.txt.bz2 On 13-04-19 4:21 AM, Richard Biener wrote: > On Fri, Apr 19, 2013 at 1:08 AM, Martin Jambor wrote: >> Hi, >> >> On Fri, Apr 19, 2013 at 12:37:58AM +0200, Steven Bosscher wrote: >>> On Fri, Apr 19, 2013 at 12:09 AM, Martin Jambor wrote: >>>> I also have not tried scheduling the hard register copy propagation >>>> pass twice and measuring the impact on compile times. Any suggestion >>>> what might be a good testcase for that? >>> I think a better question is when this would be useful in the first >>> place, and why. In other words: If you propagate hardregs before >>> shrink wrapping, what could be a source of new opportunities after >>> shrink wrapping? >> Yes, we also did that and neither I nor Honza could think of any >> potential problems there. And of course, I'd also measure how many >> statements the second run of the pass changed. I'll probably do that >> tomorrow anyway. >> >>> >>> The only things I can think of, given the current pass order, are: >>> >>> * different basic block order due to shrink wrapping >>> regcprop's effectiveness depends on the order of the basic blocks >>> (unfortunately) >>> >>> * different basic block contents due to head/tail merging (pass_jump2) >>> Head/tail merging extends some basic blocks and shortens others. The >>> elongated basic blocks may present new opportunities (regcprop is a >>> local pass). >>> >>> * different basic block contents due to dead store elimination (pass_dse2) >>> A removed dead store may also make an address calculation redundant, >>> changing the regcprop value chains. >>> >>> * different basic block contents due to peephole2 >>> A peephole2 may present new regcprop opportunities, peephole2 misses >>> the context to avoid trivial copies. >>> >>> >>> On the other hand, running regcprop earlier also helps some other >>> passes. For example, I think regcprop before jump2 may result in more >>> successful head/tail merging attempts by making more input operands >>> match, but it could hurt if_after_reload by extending live times of >>> registers. >>> >>> >>> But wouldn't it be better to avoid these argument-register pseudos >>> being assigned to callee-saved registers? Perhaps splitting the live >>> range of the pseudos before the first call on each path will do the >>> trick, and let IRA pick the right registers for you instead. >> First, where can I have a look how a live range is split? ;-) > Insert a copy and adjust all dominated uses: > > (set (new-pseudo old-pseudo)) > > ... adjust downstream uses of old-pseudo to use new-pseudo ... > >> But second, if such a call is in a loop (or accessible by more than >> one path), I wouldn't it be wrong to do that? To avoid that, I >> suppose I might end up doing another shrink-wrapping-like search for >> the right edge for prologue and actually coming up with a very similar >> result to the propagation and shrink-wrapping preparation. But I'm >> willing to try. > I suppose splitting life-ranges in general before argument setup might > make sense - I see hardreg copyprop as a hack around limitations > in register allocation. Note that life-range splitting is undone by > regular copy propagation. > > ISTR IRA splits life-ranges in loop code, so there must be already > some helpers that could be used. Vlad? > > I'd not recommend to reuse this code as actual live-range splitting is buried under a lot of code to modify IR of IRA as we need the IR after live-range splitting. Long ago I used splitting and rebuilding IR but building IR is a very time consuming procedure (I guess 1/2 of IRA) therefore the current solution is used. There is an alternative simpler code for this in IRA. The code was written by Bernd: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01531.html By the way, I have plans to do a separate register pressure decreasing pass based on live-range shrinkage and rematerialization. I found that we need this as more optimizations have a tendency to deal with this issue by themselves. May be I'll find time to do this in this year (but most probably not for gcc4.9). I am not sure even for release next after gcc4.9.