From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31256 invoked by alias); 18 Apr 2013 22:38:40 -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 31247 invoked by uid 89); 18 Apr 2013 22:38:40 -0000 X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_EG,TW_GC autolearn=ham version=3.3.1 Received: from mail-vb0-f44.google.com (HELO mail-vb0-f44.google.com) (209.85.212.44) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 18 Apr 2013 22:38:39 +0000 Received: by mail-vb0-f44.google.com with SMTP id e12so3090982vbg.3 for ; Thu, 18 Apr 2013 15:38:38 -0700 (PDT) X-Received: by 10.58.204.170 with SMTP id kz10mr9874568vec.1.1366324718284; Thu, 18 Apr 2013 15:38:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.240.13 with HTTP; Thu, 18 Apr 2013 15:37:58 -0700 (PDT) In-Reply-To: <20130418220949.GA3859@alvy.suse.cz> References: <20130417154935.GC3656@virgil.suse> <516EED6F.9030007@redhat.com> <20130418220949.GA3859@alvy.suse.cz> From: Steven Bosscher Date: Fri, 19 Apr 2013 10:02:00 -0000 Message-ID: Subject: Re: [PATCH, PR 10474] Shedule pass_cprop_hardreg before pass_thread_prologue_and_epilogue To: Jeff Law , GCC Patches Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-04/txt/msg01124.txt.bz2 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? 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. Ciao! Steven