--- Comment #12 from rguenth at gcc dot gnu dot org 2008-06-06 20:13
---
Subject: Bug 36291
Author: rguenth
Date: Fri Jun 6 20:12:27 2008
New Revision: 136502
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136502
Log:
2008-06-06 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-06-05 14:40
---
I have a working backport for 4.3.2 that get's memory usage down.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-05-28 13:54 ---
Subject: Bug 36291
Author: rguenth
Date: Wed May 28 13:54:05 2008
New Revision: 136095
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136095
Log:
2008-05-28 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-05-28 13:57
---
The situation on the trunk should be much better now. A trivial backport to
the
4.3 branch failed during bootstrap though, so that has to wait for some
investigation.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-23 14:16 ---
Ok, apart from the var annotations I give up here as far as 4.3 is concerned.
We cannot really fix the compile-time problem without skewing the heuristics
and risking fallout through that.
We already know from PR332
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-05-22 19:22 ---
That is, var annotations back to sanity:
tree-dfa.c:150 (create_var_ann) 206016: 0.0% 15094400:
3.2% 142592: 0.1% 0: 0.0% 241297
compared to originally
tree-dfa.c:153 (creat
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-22 19:15 ---
As noted in comment #1 variable annotations are a major problem (they are
duplicated for global variables, for each function the variable is referenced
from).
It happens that sharing variable annotations for globals
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-22 14:39 ---
I added gcc.c-torture/execute/20080522-1.c which points at two problems.
First we need to add referenced vars as they come (there is already
find_new_referenced_vars and some users,
tree-ssa-ccp.c:get_symbol_constan
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-22 12:48 ---
The root of all evil is the following code in add_referenced_var():
/* Scan DECL_INITIAL for pointer variables as they may contain
address arithmetic referencing the address of other
variable
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-22 12:35 ---
On the trunk things look different:
tree find ref. vars : 22.59 (13%) usr 1.08 (13%) sys 24.42 (14%) wall
815888 kB (47%) ggc
tree PTA : 1.43 ( 1%) usr 0.08 ( 1%) sys 1.39 ( 1%) wall
19
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-22 12:28 ---
One slow "leaker" of memory for large TUs is the operands_bitmap_obstack from
the operand scanner. From it the stmt annotation loaded and stored symbols
bitmaps are allocated but never freed until after the last fun
12 matches
Mail list logo