Re: optimization/9279: [3.2 regression] [Sparc] combine bug

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[Christian Ehrhardt]

The following reply was made to PR optimization/9279; it has been noted by GNATS.

From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
Cc: Matthias Klose <doko@cs.tu-berlin.de>,
  Eric Botcazou <ebotcazou@libertysurf.fr>, ebotcazou@gcc.gnu.org,
  frank@g-n-u.de, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9279: [3.2 regression] [Sparc] combine bug
Date: Wed, 29 Jan 2003 00:59:56 +0100

 On Tue, Jan 28, 2003 at 11:07:11PM +0100, Gabriel Dos_Reis wrote:
 > As I explained to Eric, I would have been pleased to apply that
 > patch.  However it turned out that it introduces (1) a performance
 > regression;
 
 I think we all agree that a (slight) performance regression is an 
 improvement compared to silent bad code generation.
 
 > (2) possibly a wrong code generation -- David gave some
 > references.
 
 I must have missed this discussion, Could you give me a pointer?
 
    regards  Christian
 
 -- 
 THAT'S ALL FOLKS!

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[ebotcazou]

Synopsis: [3.2 regression] [Sparc] combine bug

State-Changed-From-To: open->analyzed
State-Changed-By: ebotcazou
State-Changed-When: Sun Feb 16 15:00:37 2003
State-Changed-Why:
    The problem is clearly identified.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9279

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[Gabriel Dos_Reis]

The following reply was made to PR optimization/9279; it has been noted by GNATS.

From: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: Matthias Klose <doko@cs.tu-berlin.de>, frank@g-n-u.de,
   gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9279: [3.2 regression] [Sparc] combine bug
Date: Wed, 29 Jan 2003 02:29:15 +0100 (MET)

 | > As I explained to Eric, I would have been pleased to apply that
 | > patch.  However it turned out that it introduces (1) a performance
 | > regression; (2) possibly a wrong code generation -- David gave some
 | > references.
 | 
 | Note that, as I said to David, I'm very skeptical about (2) for the patch 
 | _alone_ because it simply pessimizes (however rightfully, they are just 
 | plain wrong in the general case) the values returned by two predicate 
 | functions:
 
 Sorry, I mistranslated your agreement on David's statement:
 
   >       This patch and the necessary PowerPC patch exposed other bugs in
   > the compiler regarding REG_EQUAL notes in loop unrolling:
   >
   > 2002-10-04  David Edelsohn  <edelsohn@gnu.org>
   >
   >         * unroll.c (copy_loop_body): Remove REG_EQUAL note attached to
   >         copied instruction if the note is not loop invariant.
   >
   > The patches may have other co-dependencies we do not know about.
 
   Ok.
 
 [...]
 
 | > I would suggest that, right after 3.2.2 release, interested parties
 | > investigate the issue and submit a complete patch which we would
 | > have sufficient time to test.
 | 
 | I'm not very optimistic about this happening. I guess most of the developer
 | resources will be focused on the 3.3 branch instead.
 
 Well, that is just a suggestion.  I hope 3.3 will be ready in time so 
 that 3.2-branch becomes obselete.
 
 -- Gaby

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[Gabriel Dos_Reis]

The following reply was made to PR optimization/9279; it has been noted by GNATS.

From: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
To: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
Cc: Matthias Klose <doko@cs.tu-berlin.de>,
   Eric Botcazou <ebotcazou@libertysurf.fr>, ebotcazou@gcc.gnu.org,
   frank@g-n-u.de, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9279: [3.2 regression] [Sparc] combine bug
Date: Wed, 29 Jan 2003 02:25:50 +0100 (MET)

 | > (2) possibly a wrong code generation -- David gave some
 | > references.
 | 
 | I must have missed this discussion, Could you give me a pointer?
 
 Sorry, that is part of e-mail exhancge I had with Eric Dadid
 yesterday.   Quoting him:
 
 	  This patch and the necessary PowerPC patch exposed other bugs in
   the compiler regarding REG_EQUAL notes in loop unrolling:
 
   2002-10-04  David Edelsohn  <edelsohn@gnu.org>
 
 	  * unroll.c (copy_loop_body): Remove REG_EQUAL note attached to
 	  copied instruction if the note is not loop invariant.
 
   The patches may have other co-dependencies we do not know about.
 
 Eric agreed with him.
 
 I would like to avoid last time minute patch chasing.
 
 -- Gaby

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[Eric Botcazou]

The following reply was made to PR optimization/9279; it has been noted by GNATS.

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
Cc: Matthias Klose <doko@cs.tu-berlin.de>,
 frank@g-n-u.de,
 gcc-bugs@gcc.gnu.org,
 gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9279: [3.2 regression] [Sparc] combine bug
Date: Wed, 29 Jan 2003 00:30:29 +0100

 > As I explained to Eric, I would have been pleased to apply that
 > patch.  However it turned out that it introduces (1) a performance
 > regression; (2) possibly a wrong code generation -- David gave some
 > references.
 
 Note that, as I said to David, I'm very skeptical about (2) for the patch 
 _alone_ because it simply pessimizes (however rightfully, they are just 
 plain wrong in the general case) the values returned by two predicate 
 functions:
 
 
 /* Given an expression, X, compute which bits in X can be non-zero.
    We don't care about bits outside of those defined in MODE.
 
    For most X this is simply GET_MODE_MASK (GET_MODE (MODE)), but if X is
    a shift, AND, or zero_extract, we can do better.  */
 
 static unsigned HOST_WIDE_INT
 nonzero_bits (x, mode)
 
 /* Return the number of bits at the high-order end of X that are known to
    be equal to the sign bit.  X will be used in mode MODE; if MODE is
    VOIDmode, X will be used in its own mode.  The returned value  will always
    be between 1 and the number of bits in MODE.  */
 
 static unsigned int
 num_sign_bit_copies (x, mode)
 
 
 > Therefore, to fix the new regressions we would have to grab
 > other patches not known to be safe.  The initial patch was beginning
 > to have too much ramifications.
 
 I can't disagree here.
 
 > I would suggest that, right after 3.2.2 release, interested parties
 > investigate the issue and submit a complete patch which we would
 > have sufficient time to test.
 
 I'm not very optimistic about this happening. I guess most of the developer
 resources will be focused on the 3.3 branch instead.
 
 -- 
 Eric Botcazou

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[Matthias Klose]

The following reply was made to PR optimization/9279; it has been noted by GNATS.

From: Matthias Klose <doko@cs.tu-berlin.de>
To: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
Cc: Eric Botcazou <ebotcazou@libertysurf.fr>, ebotcazou@gcc.gnu.org,
        frank@g-n-u.de, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9279: [3.2 regression] [Sparc] combine bug
Date: Tue, 28 Jan 2003 23:28:20 +0100

 Gabriel Dos_Reis writes:
 > | Eric Botcazou writes:
 > | > >     The fix introduces a performance regression for PowerPC (and possibly
 > | > > other platforms) on the 3.2 branch.
 > | > 
 > | > Now reverted for this reason on the 3.2 branch so GCC 3.2.2 will ship with 
 > | > the bug.
 > | 
 > | I see you having the choice between two regressions, one performance
 > | regression (from 3.2.1 to 3.2.2) and one "wrong code" regression (from
 > | 2.95 and 3.0.4 to 3.2.2). Not sure, if I should like your decision.
 > 
 > As I explained to Eric, I would have been pleased to apply that
 > patch.  However it turned out that it introduces (1) a performance
 > regression; (2) possibly a wrong code generation -- David gave some
 > references.  Therefore, to fix the new regressions we would have to grab 
 > other patches not known to be safe.  The initial patch was beginning
 > to have too much ramifications.  That is why I asked Eric to revert
 > his patch.
 
 Thanks for the clarification, I did miss this information on the gnats
 report.

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[Gabriel Dos_Reis]

The following reply was made to PR optimization/9279; it has been noted by GNATS.

From: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
To: Matthias Klose <doko@cs.tu-berlin.de>
Cc: Eric Botcazou <ebotcazou@libertysurf.fr>, ebotcazou@gcc.gnu.org,
   frank@g-n-u.de, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9279: [3.2 regression] [Sparc] combine bug
Date: Tue, 28 Jan 2003 23:07:11 +0100 (MET)

 | Eric Botcazou writes:
 | > >     The fix introduces a performance regression for PowerPC (and possibly
 | > > other platforms) on the 3.2 branch.
 | > 
 | > Now reverted for this reason on the 3.2 branch so GCC 3.2.2 will ship with 
 | > the bug.
 | 
 | I see you having the choice between two regressions, one performance
 | regression (from 3.2.1 to 3.2.2) and one "wrong code" regression (from
 | 2.95 and 3.0.4 to 3.2.2). Not sure, if I should like your decision.
 
 As I explained to Eric, I would have been pleased to apply that
 patch.  However it turned out that it introduces (1) a performance
 regression; (2) possibly a wrong code generation -- David gave some
 references.  Therefore, to fix the new regressions we would have to grab 
 other patches not known to be safe.  The initial patch was beginning
 to have too much ramifications.  That is why I asked Eric to revert
 his patch.  
 
 I would suggest that, right after 3.2.2 release, interested parties
 investigate the issue and submit a complete patch which we would
 have sufficient time to test.
 
 -- Gaby

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[Matthias Klose]

The following reply was made to PR optimization/9279; it has been noted by GNATS.

From: Matthias Klose <doko@cs.tu-berlin.de>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: ebotcazou@gcc.gnu.org, frank@g-n-u.de, gcc-bugs@gcc.gnu.org,
        gcc-gnats@gcc.gnu.org, gdosreis@sophia.inria.fr
Subject: Re: optimization/9279: [3.2 regression] [Sparc] combine bug
Date: Tue, 28 Jan 2003 21:46:25 +0100

 Eric Botcazou writes:
 > >     The fix introduces a performance regression for PowerPC (and possibly
 > > other platforms) on the 3.2 branch.
 > 
 > Now reverted for this reason on the 3.2 branch so GCC 3.2.2 will ship with 
 > the bug.
 
 I see you having the choice between two regressions, one performance
 regression (from 3.2.1 to 3.2.2) and one "wrong code" regression (from
 2.95 and 3.0.4 to 3.2.2). Not sure, if I should like your decision.
 
 	Matthias

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[Eric Botcazou]

The following reply was made to PR optimization/9279; it has been noted by GNATS.

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: ebotcazou@gcc.gnu.org
Cc: doko@debian.org,
 frank@g-n-u.de,
 gcc-bugs@gcc.gnu.org,
 gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9279: [3.2 regression] [Sparc] combine bug
Date: Mon, 27 Jan 2003 18:47:21 +0100

 >     The fix introduces a performance regression for PowerPC (and possibly
 > other platforms) on the 3.2 branch.
 
 Now reverted for this reason on the 3.2 branch so GCC 3.2.2 will ship with 
 the bug.
 
 -- 
 Eric Botcazou

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[ebotcazou]

Synopsis: [3.2 regression] [Sparc] combine bug

State-Changed-From-To: closed->open
State-Changed-By: ebotcazou
State-Changed-When: Mon Jan 27 17:05:35 2003
State-Changed-Why:
    The fix introduces a performance regression for PowerPC (and possibly other platforms) on the 3.2 branch.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9279

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[ebotcazou]

Synopsis: [3.2 regression] [Sparc] combine bug

State-Changed-From-To: analyzed->closed
State-Changed-By: ebotcazou
State-Changed-When: Sat Jan 25 16:12:13 2003
State-Changed-Why:
    Fixed. See http://gcc.gnu.org/ml/gcc-patches/2003-01/msg01941.html

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9279

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[ebotcazou]

Synopsis: [3.2 regression] [Sparc] combine bug

Responsible-Changed-From-To: unassigned->ebotcazou
Responsible-Changed-By: ebotcazou
Responsible-Changed-When: Fri Jan 24 16:26:59 2003
Responsible-Changed-Why:
    Evaluating a backport from mainline:
    http://gcc.gnu.org/ml/gcc-cvs/2002-07/msg00247.html

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9279

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[Christian Ehrhardt]

The following reply was made to PR optimization/9279; it has been noted by GNATS.

From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, frank@g-n-u.de,
  nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, doko@debian.org
Cc:  
Subject: Re: optimization/9279: [3.2 regression] [Sparc] combine bug
Date: Fri, 24 Jan 2003 11:57:26 +0100

 Hi,
 
 here's an even simpler example:
 
 
 int x = 0;
 char c, * p = &c, a = -1;
 int main ()
 {
 	if ((x?0:(unsigned char)((*p) = a)) == -1)
 		return 0;
 	return 1;
 }
 
 The exitcode of this program should always be 1 but it is zero if
 compiled with -O2.
 
 The problem is that these two insns
 
 (insn 24 23 25 (set (reg:SI 117)
         (zero_extend:SI (reg:QI 116))) 126 {*zero_extendqisi2_insn} (nil)
     (expr_list:REG_DEAD (reg:QI 116)
         (nil)))
 
 (insn 25 24 26 (set (reg:CC 100 %icc)
         (compare:CC (reg:SI 117)
             (const_int -1 [0xffffffffffffffff]))) 0 {*cmpsi_insn} (insn_list 24 (nil))
     (expr_list:REG_DEAD (reg:SI 117)
         (nil)))
 
 are combined into one like this:
 
 (note 24 23 25 NOTE_INSN_DELETED)
 
 (insn 25 24 26 (set (reg:CC 100 %icc)
         (compare:CC (subreg:SI (reg:QI 116) 0)
             (const_int 255 [0xff]))) 0 {*cmpsi_insn} (nil)
     (expr_list:REG_DEAD (reg:QI 116)
         (nil)))
 
    regards  Christian
 

Re: optimization/9279: [3.2 regression] [Sparc] combine bug

[ebotcazou]

Old Synopsis: 3.2 regression to 2.95 / 3.0.4 on sparc-linux
New Synopsis: [3.2 regression] [Sparc] combine bug

State-Changed-From-To: feedback->analyzed
State-Changed-By: ebotcazou
State-Changed-When: Thu Jan 23 19:44:08 2003
State-Changed-Why:
    Confirmed

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9279