public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: optimization/7147: ifcvt.c problem (regression) Date: Sun, 30 Jun 2002 19:06:00 -0000 [thread overview] Message-ID: <20020630204603.15678.qmail@sources.redhat.com> (raw) The following reply was made to PR optimization/7147; it has been noted by GNATS. From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com> To: gcc-gnats@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org, Richard Henderson <rth@redhat.com>, Mark Mitchell <mark@codesourcery.com> 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--
next reply other threads:[~2002-06-30 20:46 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-06-30 19:06 Franz Sirl [this message] -- strict thread matches above, loose matches on Subject: below -- 2002-09-29 9:42 sayle 2002-07-18 6:26 Mark Mitchell 2002-07-18 6:06 Franz Sirl 2002-07-16 14:36 Richard Henderson 2002-06-27 16:06 Franz.Sirl-kernel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20020630204603.15678.qmail@sources.redhat.com \ --to=franz.sirl-kernel@lauterbach.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).