https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #151 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:053d4dda0a205aba6af85fd9662118dd8109df9f
commit r13-6061-g053d4dda0a205aba6af85fd9662118dd8109df9f
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #150 from Richard Biener ---
For _num.i at -O2+ it's PRE / postreload GCSE via compute_transp that takes all
compile-time. The reason is all the sbitmaps used and using them "inverted"
aka
one bitmap per BB instead of one bitmap per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #149 from Richard Biener ---
(In reply to Richard Biener from comment #148)
> (In reply to lucier from comment #145)
> > Created attachment 54424 [details]
> > CPU and Memory usage reports for mainline 13.0.1 (mainline)
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #148 from Richard Biener ---
(In reply to lucier from comment #145)
> Created attachment 54424 [details]
> CPU and Memory usage reports for mainline 13.0.1 (mainline)
>
> Thank you for looking at this issue again.
>
> I built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #147 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4b19ff1b5ef684c2d9ccd4fb275aeef0a4b0b980
commit r13-5750-g4b19ff1b5ef684c2d9ccd4fb275aeef0a4b0b980
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #146 from lucier at math dot purdue.edu ---
Here are a few memory and time statistics picked from report-compiler4 that
seem to be more extreme than the others:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #145 from lucier at math dot purdue.edu ---
Created attachment 54424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54424=edit
CPU and Memory usage reports for mainline 13.0.1 (mainline)
Thank you for looking at this issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #144 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:295adfc9ed20468cdaba3afe258d57b58a8df792
commit r13-5729-g295adfc9ed20468cdaba3afe258d57b58a8df792
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #143 from Richard Biener ---
Checking with GCC 13, _num.i now behaves very nice with no obvious badness.
compiler.i behaves OK-ish, peaks are the following now
alias stmt walking : 10.33 ( 8%)
parser function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Richard Biener changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #141 from lucier at math dot purdue.edu ---
Created attachment 52027
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52027=edit
CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #140 from lucier at math dot purdue.edu ---
(In reply to Andrew Pinski from comment #139)
> Does anyone have recent #s on this testcase?
I downloaded all.i.gz from
https://www.math.purdue.edu/~lucier/gcc/test-files/bugzilla/1/
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #139 from Andrew Pinski ---
Does anyone have recent #s on this testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Bug 26854 depends on bug 66760, which changed state.
Bug 66760 Summary: [4.9 Regression] compile time regression in IPA inline
analysis on PR26854 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66760
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #138 from Adam H. Peterson ---
Disregard my comment above. I was dropped into the wrong bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Adam H. Peterson changed:
What|Removed |Added
CC||alphaetapi at hotmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #136 from Richard Biener ---
Fixed bitmap stats look like
df-problems.c:4399 (df_md_alloc)4755456: 4.4% 4755456
1842233: 7.3% 235730 124030 heap
df-problems.c:4398 (df_md_alloc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #135 from Richard Biener ---
bitmap stats seem to be confused by 1) bitmap_obstack_release not releasing
overhead of bitmaps allocated from it, 2) the DF machinery using embedded
bitmap heads which for this testcase seems to explode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #134 from Richard Biener ---
We can see from _num.i detailled stats
df_chain_block pool df-problems.c:2398 (df_chain_alloc)
152 0: 0.0% 937593072 61860737: 90.1% 24
which shows an odd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #133 from Richard Biener ---
Thanks for the update - this PR (one of the testcases) is also tracked in
http://gcc.opensuse.org/c++bench-czerny/random/ (two testcases, pr26854.c is
"all.c" and pr26854-2.c is "_num.c").
note that our
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #132 from lucier at math dot purdue.edu ---
Created attachment 37763
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37763=edit
Detailed time/memory report when compiling _num.i
Generated with
heine:~/Downloads>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #131 from lucier at math dot purdue.edu ---
Created attachment 37761
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37761=edit
time/memory report compiling _num.i with -O2
This bug, perhaps related,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #130 from Paolo Bonzini bonzini at gnu dot org ---
A late update...
all.i: with GCC 4.8.3 on a Xeon E5 v3 time is taken mostly by alias stmt
walking
alias stmt walking : 272.52 (65%) (-O2)
alias stmt walking : 116.06
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #128 from ian at gcc dot gnu.org ian at gcc dot gnu.org
2011-01-26 01:26:52 UTC ---
Author: ian
Date: Wed Jan 26 01:26:48 2011
New Revision: 169267
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169267
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Joseph S. Myers jsm28 at gcc dot gnu.org changed:
What|Removed |Added
CC||iant at google
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Ian Lance Taylor ian at airs dot com changed:
What|Removed |Added
CC||ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|4.3.6 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #123 from Daniel Berlin dberlin at gcc dot gnu.org 2011-01-18
14:54:33 UTC ---
On Tue, Jan 18, 2011 at 9:49 AM, hubicka at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Jan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #124 from Jan Hubicka hubicka at ucw dot cz 2011-01-18 15:15:01
UTC ---
This looks suspiciously like it's not using the DFS numbers
It seems that they are used, just we do a lot of queries from
register_new_assert_for
according to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #125 from Daniel Berlin dberlin at gcc dot gnu.org 2011-01-18
15:18:25 UTC ---
--- Comment #124 from Jan Hubicka hubicka at ucw dot cz 2011-01-18 15:15:01
UTC ---
This looks suspiciously like it's not using the DFS numbers
It
--- Comment #74 from lucier at math dot purdue dot edu 2008-09-10 13:39
---
This need for more memory is a regression from earlier versions of gcc.
Can this bug be marked with
[4.3/4.4 Regression]
in the subject line?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #70 from lucier at math dot purdue dot edu 2008-07-10 17:36
---
Created an attachment (id=15893)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15893action=view)
detailed memory stats for trunk revision 137644
These are the detailed memory stats for
euler-11%
--- Comment #71 from lucier at math dot purdue dot edu 2008-07-10 17:44
---
Here are additional informal comparisons of 4.2.3 with Apple's 4.0.1 and gcc
3.4.5 on mingw:
https://webmail.iro.umontreal.ca/pipermail/gambit-list/2008-July/002450.html
--
--- Comment #72 from rguenth at gcc dot gnu dot org 2008-07-10 19:37
---
The memory counters for DF even overflow ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #73 from zadeck at naturalbridge dot com 2008-07-10 19:40
---
Subject: Re: Inordinate compile times on large
routines
rguenth at gcc dot gnu dot org wrote:
--- Comment #72 from rguenth at gcc dot gnu dot org 2008-07-10 19:37
---
The memory counters for DF
--- Comment #69 from lucier at math dot purdue dot edu 2008-05-19 17:54
---
That really smashed the problem. I find the following timings without IRA:
local alloc : 8.53 ( 4%) usr 0.01 ( 0%) sys 8.59 ( 3%) wall
7073 kB ( 1%) ggc
global alloc : 30.44
--- Comment #66 from vmakarov at redhat dot com 2008-05-19 02:00 ---
The problem with IRA was in too many allocnos to be chosen for spilling. The
most tome was spent in choosing the best allocno for spilling. The patch
solving the problem is coming.
--
--- Comment #67 from vmakarov at gcc dot gnu dot org 2008-05-19 02:03
---
Subject: Bug 26854
Author: vmakarov
Date: Mon May 19 02:02:52 2008
New Revision: 135523
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135523
Log:
2008-05-18 Vladimir Makarov [EMAIL PROTECTED]
PR
--- Comment #68 from vmakarov at redhat dot com 2008-05-19 02:08 ---
The patch solving IRA problem is described in
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01093.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #65 from steven at gcc dot gnu dot org 2008-05-15 05:59 ---
integrated RA : 373.36 (66%) usr 0.33 ( 2%) sys 375.87 (64%) wall
12064 kB ( 2%) ggc
'nuff said.
Oh, not entirely yet: IRA should have more than one timevar.
--
steven at gcc dot gnu dot org
--- Comment #62 from lucier at math dot purdue dot edu 2008-05-15 02:48
---
I thought I might test the ira branch with
euler-3% /pkgs/gcc-ira/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../ira/configure --enable-checking=release
--- Comment #63 from lucier at math dot purdue dot edu 2008-05-15 02:50
---
Created an attachment (id=15639)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15639action=view)
statistics for ira branch with -fno-ira
This is the output of the command in the previous comment with
--- Comment #64 from lucier at math dot purdue dot edu 2008-05-15 02:51
---
Created an attachment (id=15640)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15640action=view)
statistics for ira branch with -fira
This is the output of the command in the previous comment with -fira
--- Comment #61 from lucier at math dot purdue dot edu 2008-01-23 15:03
---
Subject: Re: Inordinate compile times on large routines
Kenny:
Even after you backed out this latest patch the CPU usage was down
(to 203 seconds from 280 seconds on my machine) and the maximum
memory
--- Comment #60 from zadeck at gcc dot gnu dot org 2008-01-22 13:57 ---
Subject: Bug 26854
Author: zadeck
Date: Tue Jan 22 13:57:01 2008
New Revision: 131719
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131719
Log:
2008-01-22 Kenneth Zadeck [EMAIL PROTECTED]
PR
--- Comment #59 from zadeck at gcc dot gnu dot org 2008-01-20 01:49 ---
Subject: Bug 26854
Author: zadeck
Date: Sun Jan 20 01:48:25 2008
New Revision: 131670
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131670
Log:
2008-01-19 Kenneth Zadeck [EMAIL PROTECTED]
PR
--- Comment #58 from zadeck at gcc dot gnu dot org 2008-01-19 00:39 ---
Subject: Bug 26854
Author: zadeck
Date: Sat Jan 19 00:38:34 2008
New Revision: 131649
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131649
Log:
2008-01-18 Kenneth Zadeck [EMAIL PROTECTED]
--- Comment #50 from zadeck at naturalbridge dot com 2008-01-17 21:20
---
Subject:
Mark,
Am I allowed to set the target milestone for a patch or is that your job?
26854 is not going to get fixed for 4.3. We made a lot of progress on it
with the patches to 34400, but largest
--- Comment #52 from zadeck at naturalbridge dot com 2008-01-17 21:46
---
Subject: Re: Inordinate compile times on large
routines
rguenth at gcc dot gnu dot org wrote:
--- Comment #51 from rguenth at gcc dot gnu dot org 2008-01-17 21:43
---
As this isn't even marked at
--- Comment #53 from lucier at math dot purdue dot edu 2008-01-17 21:53
---
Subject: Re: Inordinate compile times on large routines
On Jan 17, 2008, at 4:46 PM, zadeck at naturalbridge dot com wrote:
just between you and me this is most likely a regression,
I, too, believe it is
--- Comment #51 from rguenth at gcc dot gnu dot org 2008-01-17 21:43
---
As this isn't even marked at a regression, you can fix it whenever you like ;)
Only regressions have a target milestone before they are actually fixed,
though.
--
--- Comment #54 from lucier at math dot purdue dot edu 2008-01-17 22:39
---
Created an attachment (id=14963)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14963action=view)
memory details for 131610
This is the detailed memory usage for the compiler
euler-5%
--- Comment #55 from zadeck at naturalbridge dot com 2008-01-17 22:57
---
Subject: Re: Inordinate compile times on large
routines
lucier at math dot purdue dot edu wrote:
--- Comment #54 from lucier at math dot purdue dot edu 2008-01-17 22:39
---
Created an attachment
--- Comment #56 from lucier at math dot purdue dot edu 2008-01-18 01:38
---
gcc is now 5-6 times faster than it was nearly two years ago when this was
first reported; many changes have made significant improvements in cpu time.
But Steven Bosscher's patch from December still improved
--- Comment #57 from zadeck at naturalbridge dot com 2008-01-18 02:10
---
Subject: Re: Inordinate compile times on large
routines
lucier at math dot purdue dot edu wrote:
--- Comment #56 from lucier at math dot purdue dot edu 2008-01-18 01:38
---
gcc is now 5-6 times
--- Comment #43 from zadeck at naturalbridge dot com 2007-12-20 14:49
---
Subject: Re: Inordinate compile times on large
routines
lucier at math dot purdue dot edu wrote:
--- Comment #42 from lucier at math dot purdue dot edu 2007-12-20 03:52
---
Created an attachment
--- Comment #45 from zadeck at naturalbridge dot com 2007-12-20 15:31
---
Subject: Re: Inordinate compile times on large
routines
stevenb dot gcc at gmail dot com wrote:
--- Comment #44 from stevenb dot gcc at gmail dot com 2007-12-20 15:08
---
Subject: Re: Inordinate
--- Comment #44 from stevenb dot gcc at gmail dot com 2007-12-20 15:08
---
Subject: Re: Inordinate compile times on large routines
On 20 Dec 2007 14:49:12 -, zadeck at naturalbridge dot com
[EMAIL PROTECTED] wrote:
--- Comment #43 from zadeck at naturalbridge dot com
--- Comment #46 from zadeck at naturalbridge dot com 2007-12-20 16:06
---
Subject: Re: Inordinate compile times on large
routines
indexes will be 0, 1, 2, 3.
there are no def-def chains, and in particular there are no artificial
def to artificial def chains. those increments
--- Comment #47 from lucier at math dot purdue dot edu 2007-12-20 16:11
---
Subject: Re: Inordinate compile times on large routines
I don't know what's happening here, the patch doesn't apply; first I get
euler-13% patch zadeck2.patch
patching file df-problems.c
patch:
--- Comment #48 from zadeck at naturalbridge dot com 2007-12-20 17:28
---
Created an attachment (id=14801)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14801action=view)
patch to count different types of def-use chains
this patch replaces the one munged by bugzilla
--
--- Comment #49 from lucier at math dot purdue dot edu 2007-12-20 18:56
---
Subject: Re: Inordinate compile times on large routines
I think this is the extra information you wanted:
real - real = 163962912
real - art = 0
art - real = 0
art - art = 0
Brad
--
--- Comment #36 from lucier at math dot purdue dot edu 2007-12-19 21:48
---
I changed the reported against field to 4.3.0 (see my previous comments).
--
lucier at math dot purdue dot edu changed:
What|Removed |Added
--- Comment #37 from steven at gcc dot gnu dot org 2007-12-19 22:13 ---
Brad,
I am looking at your dump and your backtraces (many many thanks!!!) and I think
I have an idea how to improve the situation a bit here:
Program received signal SIGINT, Interrupt.
0x004687c9 in
--- Comment #38 from lucier at math dot purdue dot edu 2007-12-19 23:31
---
Subject: Re: Inordinate compile times on large routines
On Dec 19, 2007, at 5:13 PM, steven at gcc dot gnu dot org wrote:
This may be asking a lot, but could you do something for me
please? Could you
--- Comment #39 from steven at gcc dot gnu dot org 2007-12-20 00:02 ---
We badly need a way to track memory in DF. Because DF uses alloc_pools for
almost all its data structures, the memory statistics are only recorded if you
configure with --gather-detailed-mem-stats. I think it
--- Comment #40 from lucier at math dot purdue dot edu 2007-12-20 02:29
---
Created an attachment (id=14798)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14798action=view)
detailed memory usage report
I rebuilt mainline with --enable-gather-detailed-mem-stats and this is the
--- Comment #41 from zadeck at naturalbridge dot com 2007-12-20 03:06
---
Subject: Re: Inordinate compile times on large
routines
lucier at math dot purdue dot edu wrote:
--- Comment #40 from lucier at math dot purdue dot edu 2007-12-20 02:29
---
Created an attachment
--- Comment #42 from lucier at math dot purdue dot edu 2007-12-20 03:52
---
Created an attachment (id=14799)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799action=view)
memory details for an unpatched mainline
Here is the same information without Steven's two patches for
--- Comment #27 from rguenth at gcc dot gnu dot org 2007-11-14 10:07
---
http://www.suse.de/~gcctest/c++bench/random/ tracks this testcase (on x86_64
that is).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #26 from steven at gcc dot gnu dot org 2007-11-14 09:56 ---
Could someone test this with GCC 4.3, and report the results here?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from steven at gcc dot gnu dot org 2007-11-14 12:04 ---
Then I suggest we close this bug report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #29 from lucier at math dot purdue dot edu 2007-11-14 12:40
---
Subject: Re: Inordinate compile times on large routines
It appears to me from the raw logs at
http://www.suse.de/~gcctest/c++bench/random/
that all runs except for the -O0 fail with an out-of-memory
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-11-14 13:13
---
Right - the tester is limited to using 1GB of ram artificially. I probably
need
to fix the setup to report errors instead of sofar numbers in the oom cases.
--
--- Comment #31 from lucier at math dot purdue dot edu 2007-11-14 13:37
---
Subject: Re: Inordinate compile times on large routines
To answer Steven's original question, here is a run with
euler-20% /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-11-14 14:08
---
So, re-confirmed then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #33 from dberlin at gcc dot gnu dot org 2007-11-14 16:57
---
Subject: Re: Inordinate compile times on large routines
On 14 Nov 2007 13:37:54 -, lucier at math dot purdue dot edu
[EMAIL PROTECTED] wrote:
--- Comment #31 from lucier at math dot purdue dot edu
--- Comment #35 from lucier at math dot purdue dot edu 2007-11-14 19:06
---
Subject: Re: Inordinate compile times on large routines
PS: Should the Reported against field in bugzilla be changed to
4.3.0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #34 from lucier at math dot purdue dot edu 2007-11-14 19:04
---
Subject: Re: Inordinate compile times on large routines
On Nov 14, 2007, at 11:57 AM, dberlin at dberlin dot org wrote:
Memory usage peaked at 10.3GB (just from monitoring top).
Any idea where?
Not
--- Comment #24 from lucier at math dot purdue dot edu 2007-01-10 18:49
---
Tried it again with today's 4.2.0:
euler-34% /pkgs/gcc-4.2.0-test/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/pkgs/gcc-4.2.0-test
--- Comment #25 from amacleod at redhat dot com 2007-01-10 19:47 ---
There were numerous factors in the mainline speedup of SSA-normal, including a
massive rewrite, but there are a couple of big wins that are backportable, and
were in fact considered. It was just that they were too late
--- Comment #23 from lucier at math dot purdue dot edu 2006-12-11 06:27
---
Subject: Re: Inordinate compile times on large routines
After Andrew MacLeod's changes here
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00691.html
I see
tree SSA to normal: 5.23 ( 1%) usr 0.06 (
--- Comment #18 from lucier at math dot purdue dot edu 2006-12-07 17:32
---
Well, I decided to try it with 4.3.0 on powerpc64-apple-darwin8.8.0 and didn't
get any better results:
[descartes:~/Desktop] lucier% time /pkgs/gcc-4.3.0-64/bin/gcc -mcpu=970 -m64
-no-cpp-precomp -Wall -W
--- Comment #19 from dberlin at gcc dot gnu dot org 2006-12-07 17:54
---
Subject: Re: Inordinate compile times on large routines
This is the branch that you installed your changes on, right Dan?
yes
I suppose I should try it on another architecture to see whether the problem
--- Comment #20 from dberlin at gcc dot gnu dot org 2006-12-07 17:54
---
Subject: Re: Inordinate compile times on large routines
We now spend basically no time in PTA, and about 800 seconds in
remove_ssa_form.
Sometime later on, we run out of memory and crash.
(IE it's
--- Comment #21 from lucier at math dot purdue dot edu 2006-12-07 21:51
---
Subject: Re: Inordinate compile times on large routines
I reran things on mainline on my patched RHEL box. It took almost
7GB of memory, peak, to compile this routine (this was very near the
end of cc1).
--- Comment #22 from lucier at math dot purdue dot edu 2006-12-08 01:24
---
Subject: Re: Inordinate compile times on large routines
And here's the same data for 4.2.0 branch; Dan, your changes have
clearly helped a lot.
It seems to take about 5% more memory at the maximum, though,
--- Comment #16 from lucier at math dot purdue dot edu 2006-11-30 04:36
---
I now get a segfault when trying this with the current 4.2.0 branch:
[descartes:~/Desktop] lucier% time /pkgs/gcc-4.2.0-64-test/bin/gcc -mcpu=970
-m64 -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno
--- Comment #17 from dberlin at gcc dot gnu dot org 2006-11-30 04:54
---
Subject: Re: Inordinate compile times on large routines
On 30 Nov 2006 04:36:05 -, lucier at math dot purdue dot edu
[EMAIL PROTECTED] wrote:
--- Comment #16 from lucier at math dot purdue dot edu
--- Comment #15 from amacleod at redhat dot com 2006-04-27 20:22 ---
Subject: Bug 26854
Author: amacleod
Date: Thu Apr 27 20:22:17 2006
New Revision: 113321
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113321
Log:
Implement new immediate use iterators.
2006-04-27 Andrew
--- Comment #12 from amacleod at redhat dot com 2006-04-26 18:59 ---
I have a patch to change the implementation of immediate uses forthcoming
which, as a side effect, cleans up the operand scanner time in this file:
on my x86 cross powerpc64:
before patch:
tree operand scan :
--- Comment #13 from amacleod at redhat dot com 2006-04-27 02:29 ---
The patch for speeding up the operand cache has been posted to gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01017.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #14 from amacleod at redhat dot com 2006-04-27 02:30 ---
I should point out that its a patch for mainline. Conversion to 4.1 requires
some minor tweaking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #9 from law at gcc dot gnu dot org 2006-04-20 16:13 ---
Subject: Bug 26854
Author: law
Date: Thu Apr 20 16:13:12 2006
New Revision: 113120
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113120
Log:
PR tree-optimization/26854
* tree-ssa-dse.c
--- Comment #10 from law at redhat dot com 2006-04-20 16:17 ---
PRE/FRE for mainline need some TLC on their compile-time performance as
indicated by this PR as well. They're #3 #4 respectively behind the operator
scanning code and store-ccp and way out of line when compared with the
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-04-20 16:21
---
(In reply to comment #10)
PRE/FRE for mainline need some TLC on their compile-time performance as
indicated by this PR as well. They're #3 #4 respectively behind the
operator
scanning code and store-ccp and
--- Comment #3 from law at redhat dot com 2006-04-19 06:43 ---
I'm peeking at DOM.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #4 from law at redhat dot com 2006-04-19 15:32 ---
OK, as expected, DOM was doing something totally stupid with immediate uses.
On my x86 box I've got a patch which takes us from ~250 seconds in DOM to
around 5.
I'm going to get this fix bootstrapped and regression tested,
--- Comment #5 from law at gcc dot gnu dot org 2006-04-19 22:34 ---
Subject: Bug 26854
Author: law
Date: Wed Apr 19 22:34:41 2006
New Revision: 113099
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113099
Log:
PR tree-optimization/26854
* tree-ssa-dse.c
1 - 100 of 105 matches
Mail list logo
