From patchwork Fri Mar 18 18:18:05 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 87565 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id E81A1B6F06 for ; Sat, 19 Mar 2011 05:18:28 +1100 (EST) Received: (qmail 13200 invoked by alias); 18 Mar 2011 18:18:25 -0000 Received: (qmail 13185 invoked by uid 22791); 18 Mar 2011 18:18:24 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, TW_CF, T_RP_MATCHES_RCVD 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, 18 Mar 2011 18:18:15 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2III8fA003535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Mar 2011 14:18:08 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p2III71c026444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2011 14:18:07 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (localhost.localdomain [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id p2III6MU027702; Fri, 18 Mar 2011 19:18:06 +0100 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id p2III5C0027204; Fri, 18 Mar 2011 19:18:05 +0100 Date: Fri, 18 Mar 2011 19:18:05 +0100 From: Jakub Jelinek To: Paolo Bonzini Cc: Kenneth Zadeck , gcc-patches@gcc.gnu.org, Bernd Schmidt Subject: Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156) Message-ID: <20110318181804.GF30899@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: <20110318161312.GC30899@tyan-ft48-01.lab.bos.redhat.com> <4D8386EF.1050001@naturalbridge.com> <20110318163135.GD30899@tyan-ft48-01.lab.bos.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Fri, Mar 18, 2011 at 06:45:57PM +0100, Paolo Bonzini wrote: > > Is the live problem so much more useful for crossjumping than lr problem? > > All it wants to prove is if it can safely move a couple of instructions > > across some other instructions, and the live_union bitmap that is computed > > using the live/lr problem is used to find out if registers set by the > > moved instructions are actually live at the end of those instructions > > or not.  What would be an example where live problem would allow optimizing > > more than lr? > > LIVE == LR except when you have uninitialized uses. > > Unless it is needed for correctness, I see no reason to prefer LIVE to > LR at -O1. So, looking at some rtl dumps with uninitialized vars at -O2, I see that LR out is either the same as LIVE out, or contains some extra regs (the uninitialized ones). But this all is at the end of a bb which contains insns that set those registers (can_move_insns_across is only interested in test_set registers from the merge_live bitmap). Thus I believe it is fine both for corectness and even generated code quality to just use LR (i.e. LIVE vs. LR should make no difference on the crossjumping). That said, I'm currently also bootstrapping/regtesting following patch just in case: 2011-03-18 Jakub Jelinek PR rtl-optimization/48156 * combine-stack-adj.c (rest_of_handle_stack_adjustments): Compute live problem if flag_crossjumping && optimize <= 1. Jakub --- gcc/combine-stack-adj.c.jj 2010-12-02 11:51:32.000000000 +0100 +++ gcc/combine-stack-adj.c 2011-03-18 18:02:04.000000000 +0100 @@ -551,7 +551,16 @@ gate_handle_stack_adjustments (void) static unsigned int rest_of_handle_stack_adjustments (void) { - cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0); + if (flag_crossjumping && optimize <= 1) + { + df_live_add_problem (); + df_live_set_all_dirty (); + df_analyze (); + cleanup_cfg (CLEANUP_CROSSJUMP); + df_remove_problem (df_live); + } + else + cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0); /* This is kind of a heuristic. We need to run combine_stack_adjustments even for machines with possibly nonzero TARGET_RETURN_POPS_ARGS