Re: optimization/9319: slower code generated for simple loop on linux

Re: optimization/9319: slower code generated for simple loop on linux

[ebotcazou]

Synopsis: slower code generated for simple loop on linux

State-Changed-From-To: feedback->analyzed
State-Changed-By: ebotcazou
State-Changed-When: Fri Jan 17 01:35:45 2003
State-Changed-Why:
    Looking into this anyway.

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

Re: optimization/9319: slower code generated for simple loop on linux

[ebotcazou]

Synopsis: slower code generated for simple loop on linux

State-Changed-From-To: analyzed->closed
State-Changed-By: ebotcazou
State-Changed-When: Wed Apr 16 07:09:47 2003
State-Changed-Why:
    The pessimization is fixed on CVS mainline (which will likely
    become GCC 3.4) by the new loop manipulation pass.

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

Re: optimization/9319: slower code generated for simple loop on linux

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: Amnon Cohen <amnon_cohen@yahoo.com>, gcc-bugs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9319: slower code generated for simple loop on linux
Date: Tue, 21 Jan 2003 18:05:43 -0800

 On Wed, Jan 22, 2003 at 12:09:52AM +0100, Eric Botcazou wrote:
 > Would you support relaxing the code when unrolling is disabled, in order to 
 > recover the optimization loss in that case ?
 
 No.  The notes used by loop.c would still be in the wrong place.  
 
 
 r~

Re: optimization/9319: slower code generated for simple loop on linux

[Eric Botcazou]

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

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Richard Henderson <rth@redhat.com>
Cc: Amnon Cohen <amnon_cohen@yahoo.com>,
 gcc-bugs@gcc.gnu.org,
 nobody@gcc.gnu.org,
 gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9319: slower code generated for simple loop on linux
Date: Wed, 22 Jan 2003 00:09:52 +0100

 > I don't think it's worth much time.  The only way to Really Fix
 > this is to move to CFG-based loop analysis.
 
 Yes, and the pessimization is a direct effect of the patch, not a mere si=
 de=20
 effect. Before, loops such as
 
 =09top:
  =09   /* empty */
 =09body:
 =09   if (!cond) goto end;
 =09   statement;
 =09   goto top;
 =09end:
 
 were rotated, identically to canonical loops such as
 
 =09top:
  =09   if (!cond) goto end;
 =09body:
 =09   statement;
 =09   goto top;
 =09end:
 
 into
 
 =09   goto first;
 =09top:
 =09   statement;
 =09first:
 =09   if (cond) goto top;
 
 
 Now the patch explicitly forbids that, in order to preserve the unrolling=
 =20
 pass:
 
 !      We rely on the presence of NOTE_INSN_LOOP_END_TOP_COND to mark
 !      the end of the entry condtional.  Without this, our lexical scan
 !      can't tell the difference between an entry conditional and a
 !      body conditional that exits the loop.  Mistaking the two means
 !      that we can misplace the NOTE_INSN_LOOP_CONT note, which can=20
 !      screw up loop unrolling.
 
 
 Would you support relaxing the code when unrolling is disabled, in order =
 to=20
 recover the optimization loss in that case ?
 
 --=20
 Eric Botcazou

Re: optimization/9319: slower code generated for simple loop on linux

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: Amnon Cohen <amnon_cohen@yahoo.com>, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9319: slower code generated for simple loop on linux
Date: Thu, 16 Jan 2003 19:31:44 -0800

 On Thu, Jan 16, 2003 at 08:12:03PM +0100, Eric Botcazou wrote:
 > Richard, do you think that the problem is worth looking into or that it is a 
 > lost cause ?
 
 I don't think it's worth much time.  The only way to Really Fix
 this is to move to CFG-based loop analysis.
 
 You might see if the code on cfg-brach, or rtlopt-branch fixes this.
 
 
 r~

Re: optimization/9319: slower code generated for simple loop on linux

[Eric Botcazou]

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

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Amnon Cohen <amnon_cohen@yahoo.com>
Cc: Richard Henderson <rth@redhat.com>,
 gcc-bugs@gcc.gnu.org,
 gcc-prs@gcc.gnu.org,
 nobody@gcc.gnu.org,
 gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9319: slower code generated for simple loop on linux
Date: Thu, 16 Jan 2003 20:12:03 +0100

 > I have done a few more tests, and it seems
 > that this is a regression
 > on all platforms  (not just intel) introduced by
 > gcc3.1
 
 Confirmed. The regression actually started to show up in gcc 3.0.4 (that'=
 s why=20
 I asked you to post the assembly code, I only had the 3.0.4 version on my=
 =20
 system) and has affected all versions since then.
 
 > The performance is significantly reduced on intel
 > linux and on Solaris (I have not sent solaris asm
 > files, let me know if you need them). So I do
 > not think that this is architecture related
 
 A nasty side-effect of the patch that fixed PR optimization/5076, which w=
 as=20
 foreseen by Richard: http://gcc.gnu.org/ml/gcc-patches/2002-01/msg02111.h=
 tml
 
 Richard, do you think that the problem is worth looking into or that it i=
 s a=20
 lost cause ?
 
 --=20
 Eric Botcazou

Re: optimization/9319: slower code generated for simple loop on linux

[Amnon Cohen]

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

From: Amnon Cohen <amnon_cohen@yahoo.com>
To: ebotcazou@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
  nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc: amnon@verisity.com
Subject: Re: optimization/9319: slower code generated for simple loop on linux
Date: Thu, 16 Jan 2003 05:30:27 -0800 (PST)

 --0-462841879-1042723827=:65194
 Content-Type: text/plain; charset=us-ascii
 Content-Id: 
 Content-Disposition: inline
 
 Hi ebotcazou,
 Thanks for getting back to me so fast.
 I have done a few more tests, and it seems 
 that this is a regression
 on all platforms  (not just intel) introduced by
 gcc3.1
 Note that the while loop in the example is equivalent
 to
 for (i=0; i<n; i++) s+=i;
 
 The for loop generates faster code.
 
 Another problem, if we compile with
 -funroll-all-loops,
 the loop does not get unrolled on gcc3.2.1, whereas
 it does on gcc3.0
 
 
 Here is the information you asked for.
 For the newer compiler which shows the regression
 
 >gcc321 -v
 Reading specs from
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs
 Configured with: ./configure 
 Thread model: posix
 gcc version 3.2.1
 
 Wheras the old version
 >gcc3 -v
 Reading specs from
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs
 Configured with: ./configure 
 Thread model: single
 gcc version 3.0.3
 
 I have attached the assembler files 
 (produced by gcc -S loop3.c)
 
 The performance is significantly reduced on intel
 linux and on Solaris (I have not sent solaris asm
 files, let me know if you need them). So I do 
 not think that this is architecture related
 
 Please let me know if you need any more info!
 
 - Amnon
 
 --- ebotcazou@gcc.gnu.org wrote:
 > Synopsis: slower code generated for simple loop on
 > linux
 > 
 > Responsible-Changed-From-To: unassigned->ebotcazou
 > Responsible-Changed-By: ebotcazou
 > Responsible-Changed-When: Thu Jan 16 03:58:11 2003
 > Responsible-Changed-Why:
 >     Investigating.
 > State-Changed-From-To: open->feedback
 > State-Changed-By: ebotcazou
 > State-Changed-When: Thu Jan 16 03:58:11 2003
 > State-Changed-Why:
 >     Could you provide us with more details ? What
 > does gcc -v output for each compiler ? Could you
 > post the assembly code generated for the loop by
 > each compiler (gcc -O3 -S) ? On what hardware did
 > you experience the performance hit ?
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9319
 
 __________________________________________________
 Do you Yahoo!?
 Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
 http://mailplus.yahoo.com
 --0-462841879-1042723827=:65194
 Content-Type: application/octet-stream; name="loop3.linux.gcc3.s"
 Content-Transfer-Encoding: base64
 Content-Description: loop3.linux.gcc3.s
 Content-Disposition: attachment; filename="loop3.linux.gcc3.s"
 
 CS5maWxlCSJsb29wMy5jIgoJLnRleHQKCS5hbGlnbiAxNgouZ2xvYmwgbG9v
 cDMKCS50eXBlCWxvb3AzLEBmdW5jdGlvbgpsb29wMzoKCXB1c2hsCSVlYnAK
 CXhvcmwJJWVheCwgJWVheAoJbW92bAklZXNwLCAlZWJwCgltb3ZsCTgoJWVi
 cCksICVlY3gKCXhvcmwJJWVkeCwgJWVkeAoJY21wbAklZWN4LCAlZWF4Cglq
 Z2UJLkw4CgkucDJhbGlnbiA0Ci5MNToKCWFkZGwJJWVkeCwgJWVheAoJaW5j
 bAklZWR4CgljbXBsCSVlY3gsICVlZHgKCWpsCS5MNQouTDg6Cglwb3BsCSVl
 YnAKCXJldAouTGZlMToKCS5zaXplCWxvb3AzLC5MZmUxLWxvb3AzCgkuaWRl
 bnQJIkdDQzogKEdOVSkgMy4wLjMiCg==
 
 --0-462841879-1042723827=:65194
 Content-Type: application/octet-stream; name="loop3.linux.gcc321.s"
 Content-Transfer-Encoding: base64
 Content-Description: loop3.linux.gcc321.s
 Content-Disposition: attachment; filename="loop3.linux.gcc321.s"
 
 CS5maWxlCSJsb29wMy5jIgoJLnRleHQKCS5wMmFsaWduIDQsLDE1Ci5nbG9i
 bCBsb29wMwoJLnR5cGUJbG9vcDMsQGZ1bmN0aW9uCmxvb3AzOgoJcHVzaGwJ
 JWVicAoJeG9ybAklZWR4LCAlZWR4Cgltb3ZsCSVlc3AsICVlYnAKCW1vdmwJ
 OCglZWJwKSwgJWVjeAoJeG9ybAklZWF4LCAlZWF4CgkucDJhbGlnbiA0LCwx
 NQouTDc6CgljbXBsCSVlY3gsICVlZHgKCWpnZQkuTDMKCWFkZGwJJWVkeCwg
 JWVheAoJaW5jbAklZWR4CglqbXAJLkw3Ci5MMzoKCXBvcGwJJWVicAoJcmV0
 Ci5MZmUxOgoJLnNpemUJbG9vcDMsLkxmZTEtbG9vcDMKCS5pZGVudAkiR0ND
 OiAoR05VKSAzLjIuMSIK
 
 --0-462841879-1042723827=:65194--

Re: optimization/9319: slower code generated for simple loop on linux

[ebotcazou]

Synopsis: slower code generated for simple loop on linux

Responsible-Changed-From-To: unassigned->ebotcazou
Responsible-Changed-By: ebotcazou
Responsible-Changed-When: Thu Jan 16 03:58:11 2003
Responsible-Changed-Why:
    Investigating.
State-Changed-From-To: open->feedback
State-Changed-By: ebotcazou
State-Changed-When: Thu Jan 16 03:58:11 2003
State-Changed-Why:
    Could you provide us with more details ? What does gcc -v output for each compiler ? Could you post the assembly code generated for the loop by each compiler (gcc -O3 -S) ? On what hardware did you experience the performance hit ?

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

optimization/9319: slower code generated for simple loop on linux

[amnon_cohen]

>Number:         9319
>Category:       optimization
>Synopsis:       slower code generated for simple loop on linux
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 15 02:16:02 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     amnon_cohen@yahoo.com
>Release:        gcc 3.2.1
>Organization:
>Environment:
Red Hat Linux 2.3.9-13
>Description:
For the simple loop attached gcc3.2.1 -O3 produces code
which runs 40% slower than code produced by gcc 3.0

>How-To-Repeat:
gcc -c -O3 loop3.c
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="loop3.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="loop3.c"

CmludCBsb29wMyhpbnQgbikgewoJaW50IGk9MCxzPTA7Cgl3aGlsZSAoMSkgewoJCWlmIChpID49
IG4pCgkJCWJyZWFrOwoJCWVsc2UgewoJCQlzKz1pOwoJCQlpICsrOwoJCQl9CgkJfQoJcmV0dXJu
IHM7Cn0KCg==