From patchwork Wed May 22 10:45:32 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joern Rennecke X-Patchwork-Id: 245585 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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 4513A2C00A1 for ; Wed, 22 May 2013 20:45:43 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:to:cc:subject:references:in-reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= default; b=WUmhUWPPWlqt94sgQpHy/Sjzvz8vVWDqjAs5hrUcWzECLiGdB2Lnj P7Ocb8PRN/F2lg3MsRvAcmdAfRHQFgpy35VReHt3jS8t+3p4CJO/BVV5SfnZWzqG t47QsCbPVG4fQQuzlg1ebekxFC71UPi2UueVd2al254fZ8huiDiE/8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:to:cc:subject:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=default; bh=Xjaudc+dJxAg4nx6A1QT8ALIxi0=; b=tYUUiR7jJrasL7b9aTK7ClTDqNNz WZyOdpSWrYYNDjBvcgcmFlsiJ0k4G7pQCUptySf4N+Za/mMkxTKoP/H9Ycty0iHb xGyYF3sqPEr5merEf6opghM/2YzTWp6mPdVPk7bgxXkvQMt8FKeINko7mYXrmp7N UmLLD5Igm/rqN3U= Received: (qmail 11665 invoked by alias); 22 May 2013 10:45:36 -0000 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 Received: (qmail 11647 invoked by uid 89); 22 May 2013 10:45:35 -0000 X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_MED, TW_DB autolearn=ham version=3.3.1 Received: from c62.cesmail.net (HELO c62.cesmail.net) (216.154.195.54) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 22 May 2013 10:45:34 +0000 Received: from unknown (HELO epsilon2) ([192.168.1.60]) by c62.cesmail.net with ESMTP; 22 May 2013 06:45:32 -0400 Received: from cust213-dsl91-135-11.idnet.net (cust213-dsl91-135-11.idnet.net [91.135.11.213]) by webmail.spamcop.net (Horde MIME library) with HTTP; Wed, 22 May 2013 06:45:32 -0400 Message-ID: <20130522064532.lk8zcp0dkowc8o4w-nzlynne@webmail.spamcop.net> Date: Wed, 22 May 2013 06:45:32 -0400 From: Joern Rennecke To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org Subject: Re: RFA: fix rtl-optimization/56833 References: <20130515110002.j5o6zwvv8c88c48g-nzlynne@webmail.spamcop.net> <1465225.euvHJY1BXk@polaris> In-Reply-To: <1465225.euvHJY1BXk@polaris> MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-Virus-Found: No Quoting Eric Botcazou : >> The problem was that we had some optimzations added to the >> reload_cse_move2add pass that would attempt transformations with >> multi-hard-register registers, without keeping track of the validity of the >> values in all hard registers involved. > > That's not clear to me: for example in move2add_note_store, we reset the info > about any multi hard-register; moveover 5 arrays are supposed to be > maintained > for each hard-register: > > for (i = FIRST_PSEUDO_REGISTER - 1; i >= 0; i--) > { > reg_set_luid[i] = 0; > reg_offset[i] = 0; > reg_base_reg[i] = 0; > reg_symbol_ref[i] = NULL_RTX; > reg_mode[i] = VOIDmode; > } > so I'm not sure whether we really properly handle multi hard-registers. Initializing all the values is nice to have defined contents, but the values in reg_offset[i] / reg_base_reg[i] / reg_symbol_ref[i] just tell what's in these registers if they are valid, not if they are valid. But I can see that there could be a problem with an earlier value that used to be valid in a multi-hard-register sub register to be considered to be still valid. Setting the mode of every constituent register but the first one (which has the new value recorded) to VOIDmode at the same time as updating reg_set_luid should be sufficent to address this issue. > So > what about explicitly punting for multi hard-registers in > reload_cse_move2add? > Do you think that this would pessimize too much in practice? The pass was originally written with word_mode == Pmode targets like the SH in mind, where multi-hard-register values are uninteresting. But for targets like the avr, most or all of the interesting values will be in multi-hard-register registers. 2013-05-22 Joern Rennecke PR rtl-optimization/56833 * postreload.c (move2add_use_add2_insn): Update reg_set_luid and reg_mode for all affected hard registers. (move2add_use_add3_insn): Likewise. Check that all source hard regs have been set by the same set. (reload_cse_move2add): Before concluding that we have a pre-existing value, check that all destination hard registers have been set by the same set. Index: postreload.c =================================================================== --- postreload.c (revision 199190) +++ postreload.c (working copy) @@ -1749,7 +1749,13 @@ move2add_use_add2_insn (rtx reg, rtx sym } } } - reg_set_luid[regno] = move2add_luid; + int i = hard_regno_nregs[regno][GET_MODE (reg)] -1; + do + { + reg_set_luid[regno + i] = move2add_luid; + reg_mode[regno + i] = VOIDmode; + } + while (--i >= 0); reg_base_reg[regno] = -1; reg_mode[regno] = GET_MODE (reg); reg_symbol_ref[regno] = sym; @@ -1793,6 +1799,14 @@ move2add_use_add3_insn (rtx reg, rtx sym && reg_symbol_ref[i] != NULL_RTX && rtx_equal_p (sym, reg_symbol_ref[i])) { + int j; + + for (j = hard_regno_nregs[i][reg_mode[i]] - 1; + j > 0 && reg_set_luid[i+j] == reg_set_luid[i];) + j--; + if (j != 0) + continue; + rtx new_src = gen_int_mode (INTVAL (off) - reg_offset[i], GET_MODE (reg)); /* (set (reg) (plus (reg) (const_int 0))) is not canonical; @@ -1835,7 +1849,13 @@ move2add_use_add3_insn (rtx reg, rtx sym if (validate_change (insn, &SET_SRC (pat), tem, 0)) changed = true; } - reg_set_luid[regno] = move2add_luid; + i = hard_regno_nregs[regno][GET_MODE (reg)] -1; + do + { + reg_set_luid[regno + i] = move2add_luid; + reg_mode[regno + i] = VOIDmode; + } + while (--i >= 0); reg_base_reg[regno] = -1; reg_mode[regno] = GET_MODE (reg); reg_symbol_ref[regno] = sym; @@ -1890,7 +1910,10 @@ reload_cse_move2add (rtx first) /* Check if we have valid information on the contents of this register in the mode of REG. */ - if (reg_set_luid[regno] > move2add_last_label_luid + for (i = hard_regno_nregs[regno][GET_MODE (reg)] - 1; + i > 0 && reg_set_luid[regno + i] == reg_set_luid[regno];) + i--; + if (i == 0 && reg_set_luid[regno] > move2add_last_label_luid && MODES_OK_FOR_MOVE2ADD (GET_MODE (reg), reg_mode[regno]) && dbg_cnt (cse2_move2add)) { @@ -2021,7 +2044,10 @@ reload_cse_move2add (rtx first) /* If the reg already contains the value which is sum of sym and some constant value, we can use an add2 insn. */ - if (reg_set_luid[regno] > move2add_last_label_luid + for (i = hard_regno_nregs[regno][GET_MODE (reg)] - 1; + i > 0 && reg_set_luid[regno + i] == reg_set_luid[regno];) + i--; + if (i == 0 && reg_set_luid[regno] > move2add_last_label_luid && MODES_OK_FOR_MOVE2ADD (GET_MODE (reg), reg_mode[regno]) && reg_base_reg[regno] < 0 && reg_symbol_ref[regno] != NULL_RTX