From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15695 invoked by alias); 30 Jun 2002 20:46:05 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 15679 invoked by uid 71); 30 Jun 2002 20:46:03 -0000 Date: Sun, 30 Jun 2002 19:06:00 -0000 Message-ID: <20020630204603.15678.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Franz Sirl Subject: Re: optimization/7147: ifcvt.c problem (regression) Reply-To: Franz Sirl X-SW-Source: 2002-06/txt/msg00737.txt.bz2 List-Id: The following reply was made to PR optimization/7147; it has been noted by GNATS. From: Franz Sirl To: gcc-gnats@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org, Richard Henderson , Mark Mitchell Subject: Re: optimization/7147: ifcvt.c problem (regression) Date: Sun, 30 Jun 2002 22:40:20 +0200 --------------Boundary-00=_8FDJ7SMSRRY283R9ID8T Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit On Freitag, 28. Juni 2002 00:55, Franz.Sirl-kernel@lauterbach.com wrote: > >Number: 7147 > >Category: optimization > >Synopsis: ifcvt.c problem (regression) > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: unassigned > >State: open > >Class: sw-bug > >Submitter-Id: net > >Arrival-Date: Thu Jun 27 15:56:02 PDT 2002 > >Closed-Date: > >Last-Modified: > >Originator: Franz.Sirl-kernel@lauterbach.com > >Release: current gcc-3_1-branch > >Organization: > >Environment: > > powerpc-linux-gnu > > >Description: > > This testcase is derived from a reported c++ mozilla miscompilation. It > fails at -O and works fine with -O -fexpensive-optimizations. > > My guess so far is that ifcvt.c is confused by the multiple SETs of pseudo > 117 (from .rtl): > > (insn 27 25 28 (set (reg/v:SI 117) > (reg:SI 3 r3)) -1 (nil) > (nil)) > > (insn 28 27 29 (set (reg:CC 120) > (compare:CC (reg/v:SI 117) > (const_int 0 [0x0]))) -1 (nil) > (nil)) > > (insn 29 28 31 (set (reg/v:SI 117) > (eq:SI (reg:CC 120) > (const_int 0 [0x0]))) -1 (nil) > (nil)) > > (jump_insn 31 29 32 (set (pc) > (label_ref 34)) -1 (nil) > (nil)) > > (barrier 32 31 33) > > (note 33 32 34 0x30084680 NOTE_INSN_BLOCK_END) > > (code_label 34 33 35 3 ("lab1") "" [0 uses]) > > (note 35 34 37 0x300846c0 NOTE_INSN_BLOCK_END) > > (insn 37 35 38 (set (reg:CC 121) > (compare:CC (reg/v:SI 117) > (const_int 0 [0x0]))) -1 (nil) > (nil)) > > (jump_insn 38 37 40 (set (pc) > (if_then_else (eq (reg:CC 121) > (const_int 0 [0x0])) > (label_ref 48) > (pc))) -1 (nil) > (nil)) > > > Somehow the inversion via insn 28 and 29 isn't accounted for. Actually the inversion is accounted for, but the multiple sets of pseudo reg 117 seem to confuse the compiler somehow. Richard, the comment in front of noce_get_condition seems to suggest that you weren't satisfied with the use of get_condition here anyway, so maybe WANT_REG for canonicalized_condition should always be set to limit the search range? Anyway, the appended patch fixes the testcase for me, running a full bootstrap on powerpc-linux-gnu and x86-linux-gnu now. Franz. PR optimization/7147 * ifcvt.c (noce_get_condition): Use canonicalized_condition directly. Limit scan range if !flag_expensive_optimizations. --------------Boundary-00=_8FDJ7SMSRRY283R9ID8T Content-Type: text/plain; charset="iso-8859-1"; name="gcc-pr7147.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="gcc-pr7147.patch" Index: gcc/ifcvt.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/ifcvt.c,v retrieving revision 1.78.2.5 diff -u -p -r1.78.2.5 ifcvt.c --- gcc/ifcvt.c 3 May 2002 20:24:01 -0000 1.78.2.5 +++ gcc/ifcvt.c 30 Jun 2002 20:24:35 -0000 @@ -1505,9 +1505,9 @@ noce_try_abs (if_info) } /* Look for the condition for the jump first. We'd prefer to avoid - get_condition if we can -- it tries to look back for the contents - of an original compare. On targets that use normal integers for - comparisons, e.g. alpha, this is wasteful. */ + canonicalize_condition if we can -- it tries to look back for the + contents of an original compare. On targets that use normal integers + for comparisons, e.g. alpha, this is wasteful. */ static rtx noce_get_condition (jump, earliest) @@ -1516,6 +1516,7 @@ noce_get_condition (jump, earliest) { rtx cond; rtx set; + int reverse; /* If the condition variable is a register and is MODE_INT, accept it. Otherwise, fall back on get_condition. */ @@ -1525,22 +1526,38 @@ noce_get_condition (jump, earliest) set = pc_set (jump); + /* If this branches to JUMP_LABEL when the condition is false, reverse + the condition. */ + reverse + = GET_CODE (XEXP (SET_SRC (set), 2)) == LABEL_REF + && XEXP (XEXP (SET_SRC (set), 2), 0) == JUMP_LABEL (jump); + cond = XEXP (SET_SRC (set), 0); if (GET_CODE (XEXP (cond, 0)) == REG && GET_MODE_CLASS (GET_MODE (XEXP (cond, 0))) == MODE_INT) { *earliest = jump; - /* If this branches to JUMP_LABEL when the condition is false, - reverse the condition. */ - if (GET_CODE (XEXP (SET_SRC (set), 2)) == LABEL_REF - && XEXP (XEXP (SET_SRC (set), 2), 0) == JUMP_LABEL (jump)) + if (reverse) cond = gen_rtx_fmt_ee (reverse_condition (GET_CODE (cond)), GET_MODE (cond), XEXP (cond, 0), XEXP (cond, 1)); } else - cond = get_condition (jump, earliest); + { + rtx want_reg; + + /* If this is not a standard conditional jump, we can't parse it. */ + if (GET_CODE (jump) != JUMP_INSN + || ! any_condjump_p (jump)) + return 0; + + /* With flag_expensive_optimizations unset, code maybe confused by + shared pseudos, so prevent going back too far in determining COND. */ + want_reg = flag_expensive_optimizations ? NULL_RTX : XEXP (cond, 0); + + cond = canonicalize_condition (jump, cond, reverse, earliest, want_reg); + } return cond; } --------------Boundary-00=_8FDJ7SMSRRY283R9ID8T--