[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- 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=gccview=revrev=136502 Log: 2008-06-06 Richard Guenther [EMAIL PROTECTED] PR

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- 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

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- 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=gccview=revrev=136095 Log: 2008-05-28 Richard Guenther [EMAIL PROTECTED] PR

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- 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. --

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- 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

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

-- 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

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- 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

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- 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

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- 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

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- 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,

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- 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

[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp

--- 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