https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #156 from Andrew Pinski ---
Created attachment 61159
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61159&action=edit
Preprocessed source
Adding the preprocessed source just in case the other site goes down for some
reason.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #155 from Richard Biener ---
Btw, with -fno-fold-mem-offsets -fno-ext-dce we get back to 12GB and 4min, the
remaining slowdown is tracked by PR117932.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #154 from Filip Kastl ---
> I suggest you file a new bugreport for the regression.
Ok, it is now pr117922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #153 from Richard Biener ---
(In reply to Filip Kastl from comment #152)
> I've just noticed that this bug got worse. Running
>
> time gcc -O2 all.i
>
> for GCC 14.2 gets me
>
> real 2m57.090s
> user 2m36.641s
> sys 0m20.309s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Filip Kastl changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
--- Comment #152
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)
> >
> > Thank
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 today'
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&action=edit
CPU and Memory usage reports for mainline 13.0.1 (mainline)
Thank you for looking at this issu
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 bod
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&action=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
--- 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 d
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 e
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 f
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&action=edit
Detailed time/memory report when compiling _num.i
Generated with
heine:~/Downloads> /pkgs/gcc
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&action=edit
time/memory report compiling _num.i with -O2
This bug, perhaps related,
https://gcc.gnu.org/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #130 from Paolo Bonzini ---
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 (67%) (-O1)
Requred mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #128 from 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=gcc&view=rev&rev=169267
Log:
PR tree-optimization/26854
* c-dec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #127 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Joseph S. Myers changed:
What|Removed |Added
CC||iant at google dot com
--- Comment #126
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #125 from Daniel Berlin 2011-01-18
15:18:25 UTC ---
>
> --- Comment #124 from Jan Hubicka 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 lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #124 from Jan Hubicka 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 my ^C GDB profiling.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #123 from Daniel Berlin 2011-01-18
14:54:33 UTC ---
On Tue, Jan 18, 2011 at 9:49 AM, hubicka at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
>
> Jan Hubicka changed:
>
> What |Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #122
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Richard Guenther changed:
What|Removed |Added
Target Milestone|4.3.6 |---
Summary|[4.3/4.4/4.5/4.
--- 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 #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 #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 #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
--
http://gcc.gnu.org/bugzilla/show
--- 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=15893&action=view)
detailed memory stats for trunk revision 137644
These are the detailed memory stats for
euler-11% /pkgs/g
--- 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 (14%
--- 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 #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=gcc&view=rev&rev=135523
Log:
2008-05-18 Vladimir Makarov <[EMAIL PROTECTED]>
--- 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.
--
http://gcc.gnu.org/bugzilla/
--- 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 change
--- 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=15640&action=view)
statistics for ira branch with -fira
This is the output of the command in the previous comment with -fira
--- 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=15639&action=view)
statistics for ira branch with -fno-ira
This is the output of the command in the previous comment with -fn
--- 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
--with-gmp=/pkg
--- 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 usa
--- 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=gcc&view=rev&rev=131719
Log:
2008-01-22 Kenneth Zadeck <[EMAIL PROTECTED]>
PR rtl
--- 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=gcc&view=rev&rev=131670
Log:
2008-01-19 Kenneth Zadeck <[EMAIL PROTECTED]>
PR rtl
--- 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=gcc&view=rev&rev=131649
Log:
2008-01-18 Kenneth Zadeck <[EMAIL PROTECTED]>
St
--- 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 #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 t
--- 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 #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=14963&action=view)
memory details for 131610
This is the detailed memory usage for the compiler
euler-5% /pkgs/gcc-mainline/
--- 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 #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 a
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- 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 remainin
--- 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
--
htt
--- 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=14801&action=view)
patch to count different types of def-use chains
this patch replaces the one munged by bugzilla
--
http
--- 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: malform
--- 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 increment
--- 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: Inordinat
--- 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 #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 #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=14799&action=view)
memory details for an unpatched mainline
Here is the same information without Steven's two patches for mai
--- 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 #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=14798&action=view)
detailed memory usage report
I rebuilt mainline with --enable-gather-detailed-mem-stats and this is the
ou
--- 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 would
--- 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 #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 bit
--- 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 #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 r
--- 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 #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 #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 #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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26
--- 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 failure,
--- 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 #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 #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 #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
--with-gmp=/pkgs/g
--- 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 ( 0%
--- 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 #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 #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 so
--- 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 #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 -Wno-
--- 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 #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 -f
--- 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=gcc&view=rev&rev=113321
Log:
Implement new immediate use iterators.
2006-04-27 Andrew MacL
--- 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 #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 #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 : 366.
--- 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
1 - 100 of 110 matches
Mail list logo
