From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24879 invoked by alias); 25 Feb 2008 22:26:47 -0000 Received: (qmail 24871 invoked by uid 22791); 25 Feb 2008 22:26:46 -0000 X-Spam-Check-By: sourceware.org Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 25 Feb 2008 22:26:22 +0000 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m1PMPsS4013170 for ; Mon, 25 Feb 2008 17:25:54 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1PMQKgN193730 for ; Mon, 25 Feb 2008 15:26:20 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1PMQKq2004708 for ; Mon, 25 Feb 2008 15:26:20 -0700 Received: from localhost (vervain.rchland.ibm.com [9.5.250.62]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m1PMQKsI004702; Mon, 25 Feb 2008 15:26:20 -0700 Date: Mon, 25 Feb 2008 22:30:00 -0000 From: Peter Bergner To: gcc-patches@gcc.gnu.org Subject: [PATCH] PR35371 GCSE loses track of REG_POINTER attribute Message-ID: <20080225222624.GA26857@vervain.rchland.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-IsSubscribed: yes 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 X-SW-Source: 2008-02/txt/msg01234.txt.bz2 While tracking down an unrelated performance problem, I noticed that for the following simple loop, we generate indexed form stores and that we get the ordering of the operands wrong which causes a slowdown on POWER6 (see PR28690 for more details). The culprit here is GCSE. When GCSE creates a pseudo reg to copy a reaching expression into, it fails to copy the REG_POINTER attribute over to the new pseudo. This new pseudo is then analyzed by the new code we added to PR28690 and since there is no REG_POINTER attribute, we fail to swap the operands into the correct order. This patch makes sure we inherit the REG_POINTER attribute. Is this patch ok for mainline once bootstrap and regression testing have completed? Given PR28690 was a 4.3 regression, is this ok for 4.3.1 once that is open for fixes? Peter PR rtl-optimization/35371 * gcse.c (gen_reaching_reg_rtx): New function. (pre_delete): Use it. (hoist_code): Likewise. (build_store_vectors): Likewise. (delete_store): Likewise. Index: gcse.c =================================================================== --- gcse.c (revision 132568) +++ gcse.c (working copy) @@ -818,6 +818,24 @@ gcse_main (rtx f ATTRIBUTE_UNUSED) /* Misc. utilities. */ +/* Create a pseudo reg to copy the result of a reaching expression into. + Be careful to inherit the REG_POINTER attribute. */ + +static rtx +gen_reaching_reg_rtx (rtx x) +{ + rtx reg; + + gcc_assert (REG_P (x)); + + reg = gen_reg_rtx (GET_MODE (x)); + + if (REG_POINTER (x)) + mark_reg_pointer (reg, REGNO_POINTER_ALIGN (REGNO (x))); + + return reg; +} + /* Nonzero for each mode that supports (set (reg) (reg)). This is trivially true for integer and floating point values. It may or may not be true for condition codes. */ @@ -4456,8 +4474,7 @@ pre_delete (void) expressions into. Get the mode for the new pseudo from the mode of the original destination pseudo. */ if (expr->reaching_reg == NULL) - expr->reaching_reg - = gen_reg_rtx (GET_MODE (SET_DEST (set))); + expr->reaching_reg = gen_reaching_reg_rtx (SET_DEST (set)); gcse_emit_move_after (expr->reaching_reg, SET_DEST (set), insn); delete_insn (insn); @@ -4981,7 +4998,7 @@ hoist_code (void) from the mode of the original destination pseudo. */ if (expr->reaching_reg == NULL) expr->reaching_reg - = gen_reg_rtx (GET_MODE (SET_DEST (set))); + = gen_reaching_reg_rtx (SET_DEST (set)); gcse_emit_move_after (expr->reaching_reg, SET_DEST (set), insn); delete_insn (insn); @@ -6114,7 +6131,7 @@ build_store_vectors (void) are any side effects. */ if (TEST_BIT (ae_gen[bb->index], ptr->index)) { - rtx r = gen_reg_rtx (GET_MODE (ptr->pattern)); + rtx r = gen_reaching_reg_rtx (ptr->pattern); if (dump_file) fprintf (dump_file, "Removing redundant store:\n"); replace_store_insn (r, XEXP (st, 0), bb, ptr); @@ -6437,7 +6454,7 @@ delete_store (struct ls_expr * expr, bas rtx reg, i, del; if (expr->reaching_reg == NULL_RTX) - expr->reaching_reg = gen_reg_rtx (GET_MODE (expr->pattern)); + expr->reaching_reg = gen_reaching_reg_rtx (expr->pattern); reg = expr->reaching_reg;