From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23554 invoked by alias); 13 Jan 2010 01:18:17 -0000 Received: (qmail 23482 invoked by alias); 13 Jan 2010 01:18:06 -0000 Date: Wed, 13 Jan 2010 01:18:00 -0000 Message-ID: <20100113011806.23481.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/42691] problematic REG_EQUAL note added to SUBREG In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jingyu at google dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg01433.txt.bz2 ------- Comment #6 from jingyu at google dot com 2010-01-13 01:18 ------- Subject: Re: problematic REG_EQUAL note added to SUBREG > We should try and set changed_i3_dest to 1 in this particular case as well. Here is the patch which only changes changed_i3_dest for two particular cases, where the dest of i3 really changed. The test case attached to this bug is case2. case 1: i1 = 0. i2=(parallel [(set p, ?)...]), i3=(set q, p) -> newpat=(parallel[(set q, ?),...]) -> i3.pattern=newpat case2: i1 = 0, i2=(set p, q), i3=(set subreg(s, reg(p), offset), a) ->newpat=(set p, ) -> i3.pattern=newpat Index: combine.c =================================================================== --- combine.c (revision 155801) +++ combine.c (working copy) @@ -2531,6 +2531,10 @@ try_combine (rtx i3, rtx i2, rtx i1, int newpat = p2; i3_subst_into_i2 = 1; + + /* If the result of the combination is recognized, the note of i3 + * needs to be removed. */ + changed_i3_dest = 1; goto validate_replacement; } } @@ -2667,6 +2671,10 @@ try_combine (rtx i3, rtx i2, rtx i1, int immed_double_const (olo, ohi, GET_MODE (SET_DEST (temp)))); newpat = PATTERN (i2); + + /* If the result of combination is recognized, the note of i3 needs to + * to be removed. */ + changed_i3_dest = 1; goto validate_replacement; } } @@ -3060,6 +3068,9 @@ try_combine (rtx i3, rtx i2, rtx i1, int /* Is the result of combination a valid instruction? */ insn_code_number = recog_for_combine (&newpat, i3, &new_i3_notes); + if (insn_code_number < 0) + changed_i3_dest = 0; + /* If the result isn't valid, see if it is a PARALLEL of two SETs where the second SET's destination is a register that is unused and isn't marked as an instruction that might trap in an EH region. In that case, This patch fixes the bug. Do you think if this patch is favorable? If yes, I will do dejagnu test and send it to gcc-patches for review. Thanks, Jing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691