--- Comment #27 from rguenth at gcc dot gnu dot org 2009-01-24 10:20
---
GCC 4.3.3 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from zadeck at gcc dot gnu dot org 2008-10-11 23:40 ---
Subject: Bug 37448
Author: zadeck
Date: Sat Oct 11 23:39:21 2008
New Revision: 141067
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141067
Log:
2008-10-11 Kenneth Zadeck [EMAIL PROTECTED]
PR
--- Comment #24 from zadeck at gcc dot gnu dot org 2008-10-08 02:53 ---
Subject: Bug 37448
Author: zadeck
Date: Wed Oct 8 02:52:28 2008
New Revision: 140960
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140960
Log:
2008-10-07 Kenneth Zadeck [EMAIL PROTECTED]
PR
--- Comment #25 from lucier at math dot purdue dot edu 2008-10-08 03:37
---
I'm sorry, I haven't been reading gcc-patches recently, but this is quite
similar to my patch suggested here:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01270.html
which also fixed the counters for bitmaps.
--- Comment #23 from zadeck at naturalbridge dot com 2008-09-27 12:44
---
I do not believe honza.
My measurements at -O0 on x86-42 are about 15 refs per insn.
This is based on the following stats. (These can be reproduced using a patch
that i am about to submit).
;;total ref
--- Comment #20 from hubicka at gcc dot gnu dot org 2008-09-26 21:12
---
The testcase now compiles at -O2 in resonable time.
Checking enabled compiler:
CFG verifier : 15.02 ( 5%) usr 0.01 ( 0%) sys 15.13 ( 5%) wall
0 kB ( 0%) ggc
df reaching defs : 7.57 (
--- Comment #21 from hubicka at gcc dot gnu dot org 2008-09-26 22:15
---
I've just tested Kenny's df scan ref union patch. We still have over 2.2GB
footprint that is not that much different from unpatched compiler.
allocpool statistics now give some more useful data:
df_scan_ref base
--- Comment #22 from hubicka at gcc dot gnu dot org 2008-09-26 23:34
---
With Kenny's updated df patch and updated statistics I now get:
Alloc-pool Kind Pools Elt size Allocated (elts) Peak (elts)
Leak (elts)
--- Comment #19 from vmakarov at gcc dot gnu dot org 2008-09-26 00:15
---
Subject: Bug 37448
Author: vmakarov
Date: Fri Sep 26 00:14:30 2008
New Revision: 140674
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140674
Log:
2008-09-25 Vladimir Makarov [EMAIL PROTECTED]
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-09-18 16:49
---
We seem to make nice progress on the testcase ;)
Conversion to FUD would probably help here, but looking at the DF dumps, the
testcase don't look like your average testcase showing DU/UD chain explosion.
The
--- Comment #16 from hubicka at gcc dot gnu dot org 2008-09-18 17:30
---
Subject: Bug 37448
Author: hubicka
Date: Thu Sep 18 17:28:40 2008
New Revision: 140463
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140463
Log:
PR middle-end/37448
* ipa-reference.c
--- Comment #17 from hubicka at gcc dot gnu dot org 2008-09-18 18:18
---
Subject: Bug 37448
Author: hubicka
Date: Thu Sep 18 18:16:45 2008
New Revision: 140465
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140465
Log:
PR middle-end/37448
* ipa-reference.c
--- Comment #18 from hubicka at gcc dot gnu dot org 2008-09-18 21:11
---
Hi,
some stats on instruction counts and references Kenny asked about:
At -O2:
[EMAIL PROTECTED]:~/gcc-baseline/build-ada/prev-gcc$ grep (insn
e.i.157r.outof_cfglayout | wc -l
307811
[EMAIL
--- Comment #13 from lucier at math dot purdue dot edu 2008-09-17 17:49
---
In the attached statistics file you find where this allocation overflowed
Alloc-pool KindPools Allocated PeakLeak
-
df_scan_ref
--- Comment #14 from lucier at math dot purdue dot edu 2008-09-18 01:30
---
Created an attachment (id=16351)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16351action=view)
detailed memory stats with checking enabled and long statistic counters
I reran the test problem with
--- Comment #12 from hjl at gcc dot gnu dot org 2008-09-13 15:58 ---
Subject: Bug 37448
Author: hjl
Date: Sat Sep 13 15:57:26 2008
New Revision: 140345
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140345
Log:
2008-09-13 Vladimir Makarov [EMAIL PROTECTED]
PR
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-09-11 12:36
---
Subject: Bug 37448
Author: hubicka
Date: Thu Sep 11 12:34:53 2008
New Revision: 140281
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140281
Log:
PR middle-end/37448
* tree-inline.c
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-09-11 12:40
---
Subject: Bug 37448
Author: hubicka
Date: Thu Sep 11 12:38:57 2008
New Revision: 140284
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140284
Log:
PR middle-end/37448
* cgraph.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-10 08:10 ---
On the trunk compile-time sky-rocketed there
in building the cgraph. Honza, what's going on there - it doesn't seem to
even finish ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from hubicka at gcc dot gnu dot org 2008-09-10 09:57 ---
With ENABLE_CHECKING we spend ages checking that there are no duplicated edges
in callgraph. Will fix it shortly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-09-10 10:02 ---
Now we spend eons in walking lexical blocks, since add_lexical_block called by
inliner walks till end of the chain.
Is the order of blocks important at all? (i.e. we don't insert them to proper
place anyway, just
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-09-10 11:32 ---
#0 0x0099c80d in ira_allocno_live_ranges_intersect_p (a1=0x33da8ae0,
a2=0x34395120) at ../../gcc/ira-conflicts.c:535
#1 0x0099ff0e in coalesced_allocno_conflict_p (a1=0x34e221b0,
a2=0x33da8ae0,
--- Comment #8 from hubicka at gcc dot gnu dot org 2008-09-10 11:39 ---
And at -O0 we still need about 2GB (because of dataflow leaks?), otherwise we
seem fine compilation time wise
garbage collection: 0.92 ( 3%) usr 0.00 ( 0%) sys 0.93 ( 3%) wall
0 kB ( 0%) ggc
--- Comment #9 from vmakarov at redhat dot com 2008-09-10 21:16 ---
There are 66K allocnos and 3M live ranges in function testsuite. Fixing the
problem in IRA will take some time. I hope the patch will be ready in a few
days.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
25 matches
Mail list logo
