public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/2001: [3.2/3.3 regression] Inordinately long compile times in reload CSE regs
@ 2003-03-22 12:23 paolo
0 siblings, 0 replies; 6+ messages in thread
From: paolo @ 2003-03-22 12:23 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, lucier, nobody
Synopsis: [3.2/3.3 regression] Inordinately long compile times in reload CSE regs
State-Changed-From-To: analyzed->closed
State-Changed-By: paolo
State-Changed-When: Sat Mar 22 12:23:28 2003
State-Changed-Why:
Fixed by rth with:
http://gcc.gnu.org/ml/gcc-cvs/2003-03/msg01133.html
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=2001
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/2001: [3.2/3.3 regression] Inordinately long compile times in reload CSE regs
@ 2003-03-21 23:26 Mark Mitchell
0 siblings, 0 replies; 6+ messages in thread
From: Mark Mitchell @ 2003-03-21 23:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/2001; it has been noted by GNATS.
From: Mark Mitchell <mark@codesourcery.com>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, lucier@math.purdue.edu,
nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, rth@redhat.com
Subject: Re: optimization/2001: [3.2/3.3 regression] Inordinately long
compile times in reload CSE regs
Date: 21 Mar 2003 15:17:36 -0800
On Fri, 2003-03-21 at 14:58, Steven Bosscher wrote:
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=2001
>
> Richard Henderson posted a patch for this a week ago:
> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01478.html
>
> I have successfully bootstrapped and regtested the patch on
> i586-pc-linux-gnu.
> Richard, I suppose you did the same on alpha?
>
> If so, can the patch be commited and the PR be closed?
It looks fine to me. Richard, would you commit the patch if you do not
have further reservations?
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/2001: [3.2/3.3 regression] Inordinately long compile times in reload CSE regs
@ 2003-03-21 23:06 Steven Bosscher
0 siblings, 0 replies; 6+ messages in thread
From: Steven Bosscher @ 2003-03-21 23:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/2001; it has been noted by GNATS.
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
lucier@math.purdue.edu, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org,
mark@codesourcery.com, rth@redhat.com
Cc:
Subject: Re: optimization/2001: [3.2/3.3 regression] Inordinately long compile
times in reload CSE regs
Date: Fri, 21 Mar 2003 23:58:10 +0100
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=2001
Richard Henderson posted a patch for this a week ago:
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01478.html
I have successfully bootstrapped and regtested the patch on
i586-pc-linux-gnu.
Richard, I suppose you did the same on alpha?
If so, can the patch be commited and the PR be closed?
Greetz
Steven
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/2001: [3.2/3.3 regression] Inordinately long compile times in reload CSE regs
@ 2003-03-16 10:06 Steven Bosscher
0 siblings, 0 replies; 6+ messages in thread
From: Steven Bosscher @ 2003-03-16 10:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/2001; it has been noted by GNATS.
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
lucier@math.purdue.edu, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org,
rth@redhat.com
Cc:
Subject: Re: optimization/2001: [3.2/3.3 regression] Inordinately long compile
times in reload CSE regs
Date: Sun, 16 Mar 2003 11:03:09 +0100
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=2001
Richard's patch really improves things a lot for me:
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01478.html
If somebody tries this: The patch doesn't apply cleanly, the
first hunk of bb-reorder.c needs to be applied manually.
The numbers:
GCC 3.3, March 12 sources:
at -O0: TOTAL : 4.66 0.24 6.14
at -O2: TOTAL : 316.67 1.71 329.12
GCC 3.3, March 16 sources + Richard's patch:
at -O0: TOTAL : 3.17 0.15 3.50
at -O2: TOTAL : 5.60 0.17 5.91
The latter is the avarage of three runs because I could hardly
believe these numbers.
Brad, this is worth a try, don't you think? :-)
Greetz
Steven
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/2001: [3.2/3.3 regression] Inordinately long compile times in reload CSE regs
@ 2003-03-12 19:26 Steven Bosscher
0 siblings, 0 replies; 6+ messages in thread
From: Steven Bosscher @ 2003-03-12 19:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/2001; it has been noted by GNATS.
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
lucier@math.purdue.edu, nobody@gcc.gnu.org
Cc:
Subject: Re: optimization/2001: [3.2/3.3 regression] Inordinately long compile
times in reload CSE regs
Date: Wed, 12 Mar 2003 20:19:45 +0100
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=2001
Brad Lucier wrote:
> Perhaps you were testing 3.4, where this is fixed? Or perhaps it requires
> a large number of registers before gcc screws up. Here are the times I
> now get, first for the 3.3 branch, then for 3.4:
Uhm, yes I used 3.4. I got so many gcc versions around now, picked the
wrong one.
For 3.3, I get:
at -O0: TOTAL : 4.66 0.24 6.14
at -O2: TOTAL : 316.67 1.71 329.12
Ouch.
> The patch that fixed this for 3.4 was
>
> http://gcc.gnu.org/ml/gcc-cvs/2003-02/msg00742.html
>
> Perhaps it's in the RedHat 3.2 branch, too.
Is that a combination of these two patches?
http://gcc.gnu.org./ml/gcc-patches/2003-02/msg00858.html
http://gcc.gnu.org./ml/gcc-patches/2003-02/msg01254.html
rth mentioned 3 patches, but I can only find these two, and
one other of which you said it did not apply to your sources.
Any clue why this wasn't backported to 3.3?
Greetz
Steven
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/2001: [3.2/3.3 regression] Inordinately long compile times in reload CSE regs
@ 2003-03-11 23:56 Steven Bosscher
0 siblings, 0 replies; 6+ messages in thread
From: Steven Bosscher @ 2003-03-11 23:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/2001; it has been noted by GNATS.
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
lucier@math.purdue.edu, nobody@gcc.gnu.org
Cc:
Subject: Re: optimization/2001: [3.2/3.3 regression] Inordinately long compile
times in reload CSE regs
Date: Wed, 12 Mar 2003 00:48:54 +0100
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=2001
Brad, the last time you confirmed this ugly bug is 5 months ago, do you
still see this? If so, maybe this is an Alpha-specific problem? On my
ol' slow K6-2, I get a very reasonable compile time (with -march=i586
-fPIC -O2 -fno-math-errno):
Execution times (seconds)
cfg construction : 0.09 ( 1%) usr 0.01 ( 3%) sys 0.10 ( 1%) wall
cfg cleanup : 0.33 ( 3%) usr 0.00 ( 0%) sys 0.33 ( 3%) wall
trivially dead code : 0.12 ( 1%) usr 0.00 ( 0%) sys 0.12 ( 1%) wall
life analysis : 0.39 ( 4%) usr 0.00 ( 0%) sys 0.39 ( 3%) wall
life info update : 0.14 ( 1%) usr 0.00 ( 0%) sys 0.18 ( 2%) wall
alias analysis : 0.14 ( 1%) usr 0.00 ( 0%) sys 0.14 ( 1%) wall
register scan : 0.06 ( 1%) usr 0.00 ( 0%) sys 0.06 ( 1%) wall
rebuild jump labels : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall
preprocessing : 0.10 ( 1%) usr 0.03 ( 9%) sys 0.13 ( 1%) wall
lexical analysis : 0.15 ( 2%) usr 0.07 (21%) sys 0.24 ( 2%) wall
parser : 0.64 ( 7%) usr 0.06 (18%) sys 0.90 ( 8%) wall
expand : 0.21 ( 2%) usr 0.00 ( 0%) sys 0.32 ( 3%) wall
varconst : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall
integration : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 1%) wall
jump : 0.09 ( 1%) usr 0.01 ( 3%) sys 0.10 ( 1%) wall
CSE : 0.58 ( 6%) usr 0.01 ( 3%) sys 0.60 ( 5%) wall
global CSE : 1.54 (16%) usr 0.05 (15%) sys 2.14 (18%) wall
loop analysis : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
bypass jumps : 0.24 ( 2%) usr 0.01 ( 3%) sys 0.25 ( 2%) wall
CSE 2 : 0.20 ( 2%) usr 0.00 ( 0%) sys 0.20 ( 2%) wall
branch prediction : 0.11 ( 1%) usr 0.00 ( 0%) sys 0.11 ( 1%) wall
flow analysis : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
combiner : 0.24 ( 2%) usr 0.00 ( 0%) sys 0.24 ( 2%) wall
if-conversion : 0.07 ( 1%) usr 0.00 ( 0%) sys 0.22 ( 2%) wall
regmove : 0.06 ( 1%) usr 0.00 ( 0%) sys 0.06 ( 1%) wall
local alloc : 0.20 ( 2%) usr 0.00 ( 0%) sys 0.20 ( 2%) wall
global alloc : 1.35 (14%) usr 0.04 (12%) sys 1.70 (14%) wall
reload CSE regs : 0.83 ( 9%) usr 0.02 ( 6%) sys 0.92 ( 8%) wall
flow 2 : 0.06 ( 1%) usr 0.00 ( 0%) sys 0.12 ( 1%) wall
if-conversion 2 : 0.13 ( 1%) usr 0.00 ( 0%) sys 0.13 ( 1%) wall
peephole 2 : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 1%) wall
rename registers : 0.23 ( 2%) usr 0.00 ( 0%) sys 0.26 ( 2%) wall
scheduling 2 : 0.55 ( 6%) usr 0.00 ( 0%) sys 0.58 ( 5%) wall
reorder blocks : 0.30 ( 3%) usr 0.01 ( 3%) sys 0.34 ( 3%) wall
shorten branches : 0.05 ( 1%) usr 0.00 ( 0%) sys 0.06 ( 1%) wall
final : 0.12 ( 1%) usr 0.00 ( 0%) sys 0.17 ( 1%) wall
rest of compilation : 0.16 ( 2%) usr 0.00 ( 0%) sys 0.17 ( 1%) wall
TOTAL : 9.66 0.34 11.80
Greetz
Steven
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-03-22 12:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-22 12:23 optimization/2001: [3.2/3.3 regression] Inordinately long compile times in reload CSE regs paolo
-- strict thread matches above, loose matches on Subject: below --
2003-03-21 23:26 Mark Mitchell
2003-03-21 23:06 Steven Bosscher
2003-03-16 10:06 Steven Bosscher
2003-03-12 19:26 Steven Bosscher
2003-03-11 23:56 Steven Bosscher
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).