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--
 


             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: link
Be 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).