[Bug target/30052] New: memory hog.

[Bug target/30052] New: memory hog.

[pluto at agmk dot net]

attached testcase eats a 1GB of ram, swap and it's killed by OOM.
it works fine on 4.1.2/{all} and 4.2.0/{i386,ppc}.
so, it looks like a 4.2/x86-64 target regression.


-- 
           Summary: memory hog.
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] memory hog.

[pluto at agmk dot net]

------- Comment #1 from pluto at agmk dot net  2006-12-02 17:58 -------
Created an attachment (id=12729)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12729&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] memory hog on x86-64

[pluto at agmk dot net]

------- Comment #2 from pluto at agmk dot net  2006-12-06 13:24 -------
this hog blocks xorg-xserver development/testing.


-- 

pluto at agmk dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker
            Summary|memory hog on x86           |memory hog on x86-64


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] memory hog on x86-64

[pluto at agmk dot net]

------- Comment #3 from pluto at agmk dot net  2007-01-02 20:33 -------
memhog still present with 4.2 (r120195). backtrace attached.

(gdb) bt
#0  0x00002aeaa4f19e82 in ?? () from /lib64/libc.so.6
#1  0x00002aeaa4f1b756 in malloc () from /lib64/libc.so.6
#2  0x0000000000828728 in xmalloc (size=4064) at ../../libiberty/xmalloc.c:147
#3  0x00002aeaa4f1deb2 in _obstack_newchunk () from /lib64/libc.so.6
#4  0x00000000004c46cc in bitmap_elt_insert_after (head=0x1298370,
elt=0x178321a0, indx=307) at ../../gcc/bitmap.c:122
#5  0x00000000004c4786 in bitmap_ior_into (a=0x1298370, b=<value optimized
out>) at ../../gcc/bitmap.c:1170
#6  0x0000000000733173 in set_union_with_increment (to=0x1298370,
from=0xed9df0, inc=7745) at ../../gcc/tree-ssa-structalias.c:715
#7  0x00000000007360be in solve_graph (graph=0xd5e380) at
../../gcc/tree-ssa-structalias.c:2084
#8  0x0000000000737400 in compute_points_to_sets (ai=0xd5e7e0) at
../../gcc/tree-ssa-structalias.c:4845
#9  0x0000000000489a17 in compute_may_aliases () at
../../gcc/tree-ssa-alias.c:665
#10 0x000000000071b9c8 in execute_one_pass (pass=0xb98340) at
../../gcc/passes.c:870
#11 0x000000000071bb1c in execute_pass_list (pass=0xb98340) at
../../gcc/passes.c:917
#12 0x000000000071bb2e in execute_pass_list (pass=0xb97e00) at
../../gcc/passes.c:918
#13 0x0000000000465c0e in tree_rest_of_compilation (fndecl=0x2aeaa9c8ac40) at
../../gcc/tree-optimize.c:463
#14 0x000000000040b1fc in c_expand_body (fndecl=0x2aeaa9c8ac40) at
../../gcc/c-decl.c:6814
#15 0x0000000000761064 in cgraph_expand_function (node=0x2aeaabc8d300) at
../../gcc/cgraphunit.c:1241
#16 0x000000000076197e in cgraph_optimize () at ../../gcc/cgraphunit.c:1306
#17 0x000000000040eb76 in c_write_global_declarations () at
../../gcc/c-decl.c:7929
#18 0x00000000006fdfcf in toplev_main (argc=<value optimized out>, argv=<value
optimized out>) at ../../gcc/toplev.c:1046
#19 0x00002aeaa4ec9af4 in __libc_start_main () from /lib64/libc.so.6
#20 0x0000000000402769 in _start ()


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] memory hog on x86-64

[pluto at agmk dot net]

------- Comment #4 from pluto at agmk dot net  2007-01-10 19:58 -------
hmm, if i remove this huge amount of pci*info* data structures
hog doesn't present.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] memory hog on x86-64

[arekm at pld-linux dot org]

------- Comment #5 from arekm at pld-linux dot org  2007-01-14 00:54 -------
-O0 passes

-O0 -fdefer-pop -fdelayed-branch -fguess-branch-probability -fcprop-registers
-fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce -ftree-dominator-opts
-ftree-dse -ftree-ter -ftree-lrs -ftree-sra -ftree-copyrename -ftree-fre
-ftree-ch -funit-at-a-time -fmerge-constants  -fomit-frame-pointer 

passes

-O1 fails
-O2 fails


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] memory hog on x86-64

[pluto at agmk dot net]

------- Comment #6 from pluto at agmk dot net  2007-02-12 18:25 -------
Created an attachment (id=13043)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13043&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] memory hog on x86-64

[pluto at agmk dot net]

------- Comment #7 from pluto at agmk dot net  2007-02-12 18:27 -------
x86_64-pld-linux-g++ -c -fPIC -O2 -fno-strict-aliasing -fwrapv -march=x86-64
-fno-strict-aliasing -gdwarf-2 -g2 -Wall -W -D_REENTRANT --save-temps
-ftime-report -fmem-report -DQT_NO_DEBUG -DQT_CORE_LIB -I.
-I/usr/include/python2.5 -I/usr/lib64/qt4/mkspecs/default
-I/usr/include/qt4/QtCore -I/usr/include/qt4 -I/usr/ginclude -o
sipQtCorepart0.o sipQtCorepart0.cpp
Memory still allocated at the end of the compilation process
Size   Allocated        Used    Overhead
8           8192        6920         240
16            12k       8288         264
64           112k        111k       1792
256           20k         18k        280
512           16k         14k        224
1024          64k         61k        896
2048          56k         54k        784
4096          92k         92k       1288
8192          64k         64k        448
16384         64k         64k        224
112         4096         896          56
208           16k         13k        224
192           16k         12k        224
160           48k         46k        672
176          144k        138k       2016
96          2008k       1975k         27k
416           48k         43k        672
128         8192        6912         112
48           252k        248k       4032
224          404k        396k       5656
32           192k        188k       3456
80            28k         27k        392
Total       3676k       3594k         50k

String pool
entries         21015
identifiers     21015 (100.00%)
slots           32768
bytes           308k (24k overhead)
table size      256k
coll/search     0.5458
ins/search      0.0692
avg. entry      15.05 bytes (+/- 7.88)
longest entry   57

??? tree nodes created

(No per-node statistics)
Type hash: size 1021, 382 elements, 0.255906 collisions
DECL_DEBUG_EXPR  hash: size 1021, 0 elements, 0.000000 collisions
DECL_VALUE_EXPR  hash: size 1021, 0 elements, 0.000000 collisions
no search statistics

Execution times (seconds)
 name lookup           :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 4%) wall   
  89 kB ( 3%) ggc
 TOTAL                 :   0.16             0.03             0.23              
3530 kB
Memory still allocated at the end of the compilation process
Size   Allocated        Used    Overhead
8           4096        2408         120
16          4424k       3253k         95k
64            13M       9377k        213k
256          648k        647k       9072
512          368k        262k       5152
1024        1876k       1876k         25k
2048         952k        840k         13k
4096         940k        936k         12k
8192        7480k       7472k         51k
16384       2160k       2144k       7560
32768        224k        192k        392
65536        960k        960k        840
131072        384k        256k        168
262144        768k        768k        168
112         3944k       3624k         53k
208         2704k       2267k         36k
192         2904k       1973k         39k
160         9732k       7882k        133k
176           16M       9357k        234k
96            16M         16M        237k
416           10M      10111k        151k
128         2576k       2020k         35k
48            18M       9012k        291k
224         3824k       3723k         52k
32            37M         37M        674k
80            11M         11M        166k
Total        171M        143M       2540k

String pool
entries         91552
identifiers     91552 (100.00%)
slots           131072
bytes           1432k (103k overhead)
table size      1024k
coll/search     1.3361
ins/search      0.1857
avg. entry      16.02 bytes (+/- 10.91)
longest entry   430

??? tree nodes created

(No per-node statistics)
Type hash: size 16381, 8503 elements, 1.014345 collisions
DECL_DEBUG_EXPR  hash: size 1021, 47 elements, 0.107877 collisions
DECL_VALUE_EXPR  hash: size 1021, 0 elements, 0.000000 collisions
RESTRICT_BASE    hash: size 509, 12 elements, 0.020408 collisions
no search statistics

Execution times (seconds)
 garbage collection    :   0.29 ( 0%) usr   0.00 ( 0%) sys   0.30 ( 0%) wall   
   0 kB ( 0%) ggc
 callgraph construction:   0.12 ( 0%) usr   0.01 ( 1%) sys   0.15 ( 0%) wall   
4866 kB ( 1%) ggc
 callgraph optimization:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
 388 kB ( 0%) ggc
 ipa reference         :   0.05 ( 0%) usr   0.01 ( 1%) sys   0.06 ( 0%) wall   
 100 kB ( 0%) ggc
 ipa pure const        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 ipa type escape       :   0.06 ( 0%) usr   0.01 ( 1%) sys   0.07 ( 0%) wall   
   0 kB ( 0%) ggc
 cfg cleanup           :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%) wall   
 372 kB ( 0%) ggc
 trivially dead code   :   0.11 ( 0%) usr   0.00 ( 0%) sys   0.10 ( 0%) wall   
   0 kB ( 0%) ggc
 life analysis         :   0.40 ( 0%) usr   0.00 ( 0%) sys   0.52 ( 0%) wall   
3401 kB ( 0%) ggc
 life info update      :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.10 ( 0%) wall   
   1 kB ( 0%) ggc
 alias analysis        :   0.24 ( 0%) usr   0.00 ( 0%) sys   0.23 ( 0%) wall   
5447 kB ( 1%) ggc
 register scan         :   0.13 ( 0%) usr   0.00 ( 0%) sys   0.42 ( 0%) wall   
  45 kB ( 0%) ggc
 rebuild jump labels   :   0.04 ( 0%) usr   0.01 ( 1%) sys   0.06 ( 0%) wall   
   0 kB ( 0%) ggc
 preprocessing         :   0.12 ( 0%) usr   0.06 ( 3%) sys   0.15 ( 0%) wall   
1644 kB ( 0%) ggc
 parser                :   1.00 ( 0%) usr   0.19 (11%) sys   1.20 ( 0%) wall 
102901 kB (15%) ggc
 name lookup           :   0.10 ( 0%) usr   0.08 ( 4%) sys   0.30 ( 0%) wall   
9417 kB ( 1%) ggc
 integration           :   0.16 ( 0%) usr   0.00 ( 0%) sys   0.14 ( 0%) wall  
12245 kB ( 2%) ggc
 tree gimplify         :   0.18 ( 0%) usr   0.01 ( 1%) sys   0.20 ( 0%) wall  
13731 kB ( 2%) ggc
 tree eh               :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
1814 kB ( 0%) ggc
 tree CFG construction :   0.02 ( 0%) usr   0.01 ( 1%) sys   0.03 ( 0%) wall  
12358 kB ( 2%) ggc
 tree CFG cleanup      :   0.20 ( 0%) usr   0.00 ( 0%) sys   0.21 ( 0%) wall   
 293 kB ( 0%) ggc
 tree VRP              :   0.19 ( 0%) usr   0.00 ( 0%) sys   0.21 ( 0%) wall   
4914 kB ( 1%) ggc
 tree copy propagation :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.10 ( 0%) wall   
1020 kB ( 0%) ggc
 tree store copy prop  :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
 505 kB ( 0%) ggc
 tree find ref. vars   :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
4971 kB ( 1%) ggc
 tree PTA              : 204.64 (78%) usr   0.80 (44%) sys 224.75 (78%) wall 
111448 kB (16%) ggc
 tree alias analysis   :  23.01 ( 9%) usr   0.30 (17%) sys  24.31 ( 8%) wall 
234847 kB (33%) ggc
 tree PHI insertion    :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
 584 kB ( 0%) ggc
 tree SSA rewrite      :   0.21 ( 0%) usr   0.00 ( 0%) sys   0.24 ( 0%) wall   
8201 kB ( 1%) ggc
 tree SSA other        :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SSA incremental  :   0.99 ( 0%) usr   0.01 ( 1%) sys   1.40 ( 0%) wall   
 758 kB ( 0%) ggc
 tree operand scan     :  20.46 ( 8%) usr   0.10 ( 6%) sys  22.14 ( 8%) wall  
21781 kB ( 3%) ggc
 dominator optimization:   0.26 ( 0%) usr   0.00 ( 0%) sys   0.30 ( 0%) wall   
5721 kB ( 1%) ggc
 tree SRA              :   0.08 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall   
 294 kB ( 0%) ggc
 tree STORE-CCP        :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
 503 kB ( 0%) ggc
 tree CCP              :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall   
 568 kB ( 0%) ggc
 tree split crit edges :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
1646 kB ( 0%) ggc
 tree reassociation    :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
  34 kB ( 0%) ggc
 tree PRE              :   0.25 ( 0%) usr   0.01 ( 1%) sys   0.27 ( 0%) wall   
5578 kB ( 1%) ggc
 tree FRE              :   0.11 ( 0%) usr   0.00 ( 0%) sys   0.13 ( 0%) wall   
4997 kB ( 1%) ggc
 tree code sinking     :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
  32 kB ( 0%) ggc
 tree linearize phis   :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.18 ( 0%) wall   
  27 kB ( 0%) ggc
 tree forward propagate:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
 573 kB ( 0%) ggc
 tree conservative DCE :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall   
   0 kB ( 0%) ggc
 tree aggressive DCE   :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall   
   0 kB ( 0%) ggc
 tree DSE              :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
 170 kB ( 0%) ggc
 PHI merge             :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
 138 kB ( 0%) ggc
 loop invariant motion :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 scev constant prop    :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
  38 kB ( 0%) ggc
 tree SSA uncprop      :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SSA to normal    :   0.14 ( 0%) usr   0.00 ( 0%) sys   0.12 ( 0%) wall   
3144 kB ( 0%) ggc
 tree rename SSA copies:   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 dominance frontiers   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
   0 kB ( 0%) ggc
 dominance computation :   0.29 ( 0%) usr   0.00 ( 0%) sys   0.33 ( 0%) wall   
   0 kB ( 0%) ggc
 expand                :   2.02 ( 1%) usr   0.04 ( 2%) sys   2.08 ( 1%) wall  
39944 kB ( 6%) ggc
 varconst              :   0.08 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%) wall   
 710 kB ( 0%) ggc
 jump                  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
 726 kB ( 0%) ggc
 CSE                   :   0.57 ( 0%) usr   0.01 ( 1%) sys   0.72 ( 0%) wall   
3532 kB ( 0%) ggc
 loop analysis         :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
 715 kB ( 0%) ggc
 global CSE            :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
   0 kB ( 0%) ggc
 CPROP 1               :   0.10 ( 0%) usr   0.00 ( 0%) sys   0.12 ( 0%) wall   
1052 kB ( 0%) ggc
 PRE                   :   0.15 ( 0%) usr   0.00 ( 0%) sys   0.15 ( 0%) wall   
 502 kB ( 0%) ggc
 CPROP 2               :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall   
 715 kB ( 0%) ggc
 bypass jumps          :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.10 ( 0%) wall   
 662 kB ( 0%) ggc
 CSE 2                 :   0.40 ( 0%) usr   0.00 ( 0%) sys   0.47 ( 0%) wall   
2153 kB ( 0%) ggc
 branch prediction     :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
 255 kB ( 0%) ggc
 flow analysis         :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 combiner              :   0.41 ( 0%) usr   0.01 ( 1%) sys   0.49 ( 0%) wall   
3729 kB ( 1%) ggc
 if-conversion         :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
 196 kB ( 0%) ggc
 regmove               :   0.17 ( 0%) usr   0.00 ( 0%) sys   0.12 ( 0%) wall   
 389 kB ( 0%) ggc
 local alloc           :   0.56 ( 0%) usr   0.00 ( 0%) sys   0.66 ( 0%) wall   
4120 kB ( 1%) ggc
 global alloc          :   0.57 ( 0%) usr   0.00 ( 0%) sys   0.56 ( 0%) wall   
3302 kB ( 0%) ggc
 reload CSE regs       :   0.30 ( 0%) usr   0.00 ( 0%) sys   0.28 ( 0%) wall   
3609 kB ( 1%) ggc
 flow 2                :   0.05 ( 0%) usr   0.01 ( 1%) sys   0.05 ( 0%) wall   
2992 kB ( 0%) ggc
 if-conversion 2       :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   5 kB ( 0%) ggc
 peephole 2            :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.13 ( 0%) wall   
 628 kB ( 0%) ggc
 rename registers      :   0.12 ( 0%) usr   0.00 ( 0%) sys   0.13 ( 0%) wall   
  44 kB ( 0%) ggc
 scheduling 2          :   0.63 ( 0%) usr   0.00 ( 0%) sys   0.74 ( 0%) wall   
6840 kB ( 1%) ggc
 machine dep reorg     :   0.13 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall   
  85 kB ( 0%) ggc
 reorder blocks        :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall   
2011 kB ( 0%) ggc
 final                 :   0.33 ( 0%) usr   0.04 ( 2%) sys   0.40 ( 0%) wall   
5874 kB ( 1%) ggc
 symout                :   0.45 ( 0%) usr   0.05 ( 3%) sys   0.58 ( 0%) wall  
35050 kB ( 5%) ggc
 variable tracking     :   0.18 ( 0%) usr   0.00 ( 0%) sys   0.25 ( 0%) wall   
3314 kB ( 0%) ggc
 TOTAL                 : 262.28             1.80           288.10            
708068 kB


0x000000000052ea0d in bitmap_ior_into (a=0x16e5cb0, b=<value optimized out>) at
gcc/bitmap.c:1198
1198    gcc/bitmap.c: No such file or directory.
        in gcc/bitmap.c
(gdb) bt
#0  0x000000000052ea0d in bitmap_ior_into (a=0x16e5cb0, b=<value optimized
out>) at gcc/bitmap.c:1198
#1  0x000000000079d123 in set_union_with_increment (to=0x16e5cb0,
from=0x1574ac0, inc=18446744073709551615) at gcc/tree-ssa-structalias.c:715
#2  0x00000000007a007e in solve_graph (graph=0x13f75c0) at
gcc/tree-ssa-structalias.c:2084
#3  0x00000000007a13b0 in compute_points_to_sets (ai=0x146bdd0) at
gcc/tree-ssa-structalias.c:4845
#4  0x00000000004f39d7 in compute_may_aliases () at gcc/tree-ssa-alias.c:665
#5  0x00000000007859f8 in execute_one_pass (pass=0xcddf70) at gcc/passes.c:870
#6  0x0000000000785b5c in execute_pass_list (pass=0xcddf70) at gcc/passes.c:920
#7  0x0000000000785b6e in execute_pass_list (pass=0xc1eae0) at gcc/passes.c:921
#8  0x00000000004cfb9e in tree_rest_of_compilation (fndecl=0x2b8ee7ea8c40) at
gcc/tree-optimize.c:463
#9  0x00000000004730c9 in expand_body (fn=0x2b8ee7ea8c40) at
gcc/cp/semantics.c:3075
#10 0x00000000007c75f4 in cgraph_expand_function (node=0x2b8ee7e98e40) at
gcc/cgraphunit.c:1241
#11 0x00000000007c7f0e in cgraph_optimize () at gcc/cgraphunit.c:1306
#12 0x000000000044126f in cp_finish_file () at gcc/cp/decl2.c:3347
#13 0x00000000004b58ca in c_common_parse_file (set_yydebug=<value optimized
out>) at gcc/c-opts.c:1176
#14 0x0000000000767a03 in toplev_main (argc=<value optimized out>, argv=<value
optimized out>) at gcc/toplev.c:1033
#15 0x00002b8ee30c0954 in __libc_start_main () from /lib64/libc.so.6
#16 0x0000000000402769 in _start ()


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] possible quadratic behaviour.

[dberlin at gcc dot gnu dot org]

------- Comment #8 from dberlin at gcc dot gnu dot org  2007-02-12 20:47 -------
Does this work on mainline with no real issue?

If so, i'll try to backport the solver changes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #9 from pluto at agmk dot net  2007-02-13 10:37 -------
(In reply to comment #8)
> Does this work on mainline with no real issue?
> 
> If so, i'll try to backport the solver changes.
> 

gcc43 works faster, but still needs lot of memory.

(...)
 tree PTA              :   1.33 ( 2%) usr   0.01 ( 1%) sys   1.41 ( 2%) wall  
10753 kB ( 2%) ggc
 tree alias analysis   :  14.10 (21%) usr   0.08 ( 8%) sys  14.75 (21%) wall  
55882 kB (10%) ggc
(...)
 TOTAL                 :  68.67             1.03            71.55            
537971 kB

btw.
sipQtGuipart0.ii from PyQt-x11-gpl-4.1.1 needs over 1GB of ram at -O1 :(


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] possible quadratic behaviour.

[dberlin at dberlin dot org]

------- Comment #10 from dberlin at gcc dot gnu dot org  2007-02-13 16:17 -------
Subject: Re:  possible quadratic behaviour.

On 13 Feb 2007 10:37:55 -0000, pluto at agmk dot net
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #9 from pluto at agmk dot net  2007-02-13 10:37 -------
> (In reply to comment #8)
> > Does this work on mainline with no real issue?
> >
> > If so, i'll try to backport the solver changes.
> >
>
> gcc43 works faster, but still needs lot of memory.

Yeah, but you need to show me that the reason it needs a lot of memory
is due to pta:

>
> (...)
>  tree PTA              :   1.33 ( 2%) usr   0.01 ( 1%) sys   1.41 ( 2%) wall
> 10753 kB ( 2%) ggc
>  tree alias analysis   :  14.10 (21%) usr   0.08 ( 8%) sys  14.75 (21%) wall
> 55882 kB (10%) ggc
> (...)
>  TOTAL                 :  68.67             1.03            71.55
> 537971 kB
>

Except that 55 meg and 10 meg of 512meg of gc memory is not a lot,
relatively speaking (It's not like it's 90% of the ggc memory or
something).

Also, alias analysis and PTA use heap memory that will not show up here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #11 from pluto at agmk dot net  2007-02-14 08:18 -------
(In reply to comment #10)

> Also, alias analysis and PTA use heap memory that will not show up here.

so, how can i diagnose the gcc heap usage?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] possible quadratic behaviour.

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2007-03-14 14:15 -------
*** Bug 31172 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] [4.2 Regression] possible quadratic behaviour.

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2007-03-14 14:21 -------
It's really all PTA memory.

Mainline:

 tree PTA              :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
  40 kB ( 0%) ggc
 TOTAL                 :   2.18             1.05             3.44             
48857 kB

max. VM usage: 63MB

4.2:

 tree PTA              :  18.41 (88%) usr   1.08 (53%) sys  20.32 (85%) wall   
3903 kB ( 8%) ggc
 TOTAL                 :  20.92             2.02            23.94             
48672 kB

max. VM usage: 1.1GB

4.1.2 uses 56MB.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-03-14 14:21:37
               date|                            |
            Summary|possible quadratic          |[4.2 Regression] possible
                   |behaviour.                  |quadratic behaviour.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] [4.2 Regression] possible quadratic behaviour.

[dberlin at gcc dot gnu dot org]

------- Comment #14 from dberlin at gcc dot gnu dot org  2007-03-14 15:12 -------
(In reply to comment #13)
> It's really all PTA memory.
> 
> Mainline:
> 
>  tree PTA              :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
>   40 kB ( 0%) ggc
>  TOTAL                 :   2.18             1.05             3.44             
> 48857 kB
> 
> max. VM usage: 63MB
> 
> 4.2:
> 
>  tree PTA              :  18.41 (88%) usr   1.08 (53%) sys  20.32 (85%) wall   
> 3903 kB ( 8%) ggc
>  TOTAL                 :  20.92             2.02            23.94             
> 48672 kB
> 
> max. VM usage: 1.1GB
> 
> 4.1.2 uses 56MB.
I'll backport the changes (this is more or less copying tree-ssa-structalias.c
from 4.3 to 4.2 and modifying the few things that changed in 4.3 :P)

> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #15 from pluto at agmk dot net  2007-04-25 21:56 -------
(In reply to comment #14)

> > 4.1.2 uses 56MB.
> I'll backport the changes (this is more or less copying tree-ssa-structalias.c
> from 4.3 to 4.2 and modifying the few things that changed in 4.3 :P)

Daniel, are you working on it?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] [4.2 Regression] possible quadratic behaviour.

[dberlin at dberlin dot org]

------- Comment #16 from dberlin at gcc dot gnu dot org  2007-04-26 02:20 -------
Subject: Re:  [4.2 Regression] possible quadratic behaviour.

On 25 Apr 2007 20:56:24 -0000, pluto at agmk dot net
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #15 from pluto at agmk dot net  2007-04-25 21:56 -------
> (In reply to comment #14)
>
> > > 4.1.2 uses 56MB.
> > I'll backport the changes (this is more or less copying tree-ssa-structalias.c
> > from 4.3 to 4.2 and modifying the few things that changed in 4.3 :P)
>
> Daniel, are you working on it?

So, i gave it the old college try, and it turns out to be much harder
than I expected because of mem-ssa and other changes that went into
4.3
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] [4.2 Regression] possible quadratic behaviour.

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #17 from pluto at agmk dot net  2007-05-14 20:02 -------
(In reply to comment #16)
> So, i gave it the old college try, and it turns out to be much harder
> than I expected because of mem-ssa and other changes that went into
> 4.3

yup, looks like a nice bullet for 4.2.0 release.
with such features 4.2 will be widely /dev/nulled.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] [4.2 Regression] possible quadratic behaviour.

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2007-05-18 10:14 -------
*** Bug 31984 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |m dot vegni at it-systems
                   |                            |dot it


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug target/30052] [4.2 Regression] possible quadratic behaviour.

[dberlin at gcc dot gnu dot org]

------- Comment #19 from dberlin at gcc dot gnu dot org  2007-05-18 14:46 -------
Created an attachment (id=13576)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13576&action=view)
Possible patch

The attached is a huge backport of the 4.3 solver changes.
I have only minimally tested it.
Let me know if it helps on memory usage, and I will bootstrap/regtest it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |tree-optimization
   Target Milestone|---                         |4.2.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[m dot vegni at it-systems dot it]

------- Comment #20 from m dot vegni at it-systems dot it  2007-05-18 23:31 -------
Subject: Re:  [4.2 Regression] possible quadratic behaviour.

Testsuite ran on i686-pc-linux-gnu without failures (i've enabled c and
c++ only).

xorg-server now compiles as well.

The patch deserves more testing but IMHO it's in the right direction.

Massimiliano Vegni
IT SYSTEMS srl
Roma, Italy


dberlin at gcc dot gnu dot org wrote:
> ------- Comment #19 from dberlin at gcc dot gnu dot org  2007-05-18 14:46 -------
> Created an attachment (id=13576)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13576&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13576&action=view)
> Possible patch
> 
> The attached is a huge backport of the 4.3 solver changes.
> I have only minimally tested it.
> Let me know if it helps on memory usage, and I will bootstrap/regtest it.
> 
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #21 from pluto at agmk dot net  2007-05-19 15:30 -------
with this patc gcc works much better.

xf86ScanPci.i         : 84MB / ~5sec.
sipQtCorepart0.ii.bz2 : 340MB / ~440sec.

gcc/g++ testsuite on x86_64 shows no new regressions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

Re: [Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[Daniel Berlin]

On 19 May 2007 14:30:43 -0000, pluto at agmk dot net
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #21 from pluto at agmk dot net  2007-05-19 15:30 -------
> with this patc gcc works much better.
>
> xf86ScanPci.i         : 84MB / ~5sec.
> sipQtCorepart0.ii.bz2 : 340MB / ~440sec

There are optimizations that could be made to the 440 seconds if they
are in PTA solving, but they wouldn't really help mainline much, so
i'm not sure if it is worth it.

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[dberlin at dberlin dot org]

------- Comment #22 from dberlin at gcc dot gnu dot org  2007-05-19 17:30 -------
Subject: Re:  [4.2 Regression] possible quadratic behaviour.

On 19 May 2007 14:30:43 -0000, pluto at agmk dot net
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #21 from pluto at agmk dot net  2007-05-19 15:30 -------
> with this patc gcc works much better.
>
> xf86ScanPci.i         : 84MB / ~5sec.
> sipQtCorepart0.ii.bz2 : 340MB / ~440sec

There are optimizations that could be made to the 440 seconds if they
are in PTA solving, but they wouldn't really help mainline much, so
i'm not sure if it is worth it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #23 from pluto at agmk dot net  2007-05-19 18:16 -------
bad news, this patch ices fortran build:

(...)
../../../libgfortran/intrinsics/selected_int_kind.f90:22: internal compiler
error: in process_constraint, at tree-ssa-structalias.c:2260


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[dberlin at dberlin dot org]

------- Comment #24 from dberlin at gcc dot gnu dot org  2007-05-19 18:43 -------
Subject: Re:  [4.2 Regression] possible quadratic behaviour.

On 19 May 2007 17:16:35 -0000, pluto at agmk dot net
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #23 from pluto at agmk dot net  2007-05-19 18:16 -------
> bad news, this patch ices fortran build:
>
> (...)
> ../../../libgfortran/intrinsics/selected_int_kind.f90:22: internal compiler
> error: in process_constraint, at tree-ssa-structalias.c:2260

Meh, send me the file.
This is just a small bug somewhere in the backport.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

Re: [Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[Daniel Berlin]

On 19 May 2007 17:16:35 -0000, pluto at agmk dot net
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #23 from pluto at agmk dot net  2007-05-19 18:16 -------
> bad news, this patch ices fortran build:
>
> (...)
> ../../../libgfortran/intrinsics/selected_int_kind.f90:22: internal compiler
> error: in process_constraint, at tree-ssa-structalias.c:2260

Meh, send me the file.
This is just a small bug somewhere in the backport.

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #25 from pluto at agmk dot net  2007-05-20 05:57 -------
Subject: Re:  [4.2 Regression] possible quadratic behaviour.

On Saturday 19 of May 2007 19:43:33 dberlin at dberlin dot org wrote:
> ------- Comment #24 from dberlin at gcc dot gnu dot org  2007-05-19 18:43
> ------- Subject: Re:  [4.2 Regression] possible quadratic behaviour.
>
> On 19 May 2007 17:16:35 -0000, pluto at agmk dot net
>
> <gcc-bugzilla@gcc.gnu.org> wrote:
> > ------- Comment #23 from pluto at agmk dot net  2007-05-19 18:16 -------
> > bad news, this patch ices fortran build:
> >
> > (...)
> > ../../../libgfortran/intrinsics/selected_int_kind.f90:22: internal
> > compiler error: in process_constraint, at tree-ssa-structalias.c:2260
>
> Meh, send me the file.
> This is just a small bug somewhere in the backport.


------- Comment #26 from pluto at agmk dot net  2007-05-20 05:57 -------
Created an attachment (id=13585)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13585&action=view)


------- Comment #27 from pluto at agmk dot net  2007-05-20 05:57 -------
Created an attachment (id=13586)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13586&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

Re: [Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[Daniel Berlin]

On 20 May 2007 04:57:45 -0000, pluto at agmk dot net
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #25 from pluto at agmk dot net  2007-05-20 05:57 -------
> Subject: Re:  [4.2 Regression] possible quadratic behaviour.
>

> --
>

Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var =
vi->id instead of rhs.var = id

Remove the id variable declaration.

This would have only affected fortran ....

>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
>
>

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[dberlin at dberlin dot org]

------- Comment #28 from dberlin at gcc dot gnu dot org  2007-05-20 23:52 -------
Subject: Re:  [4.2 Regression] possible quadratic behaviour.

On 20 May 2007 04:57:45 -0000, pluto at agmk dot net
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #25 from pluto at agmk dot net  2007-05-20 05:57 -------
> Subject: Re:  [4.2 Regression] possible quadratic behaviour.
>

> --
>

Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var =
vi->id instead of rhs.var = id

Remove the id variable declaration.

This would have only affected fortran ....

>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
>
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #29 from pluto at agmk dot net  2007-05-21 17:01 -------
(In reply to comment #28)
> Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var =
> vi->id instead of rhs.var = id
> 
> Remove the id variable declaration.
> 
> This would have only affected fortran ....

thx, this change fixes bootstrap.
will you commit this for 4.2.1?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[dberlin at dberlin dot org]

------- Comment #30 from dberlin at gcc dot gnu dot org  2007-05-21 17:53 -------
Subject: Re:  [4.2 Regression] possible quadratic behaviour.

On 21 May 2007 16:01:29 -0000, pluto at agmk dot net
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #29 from pluto at agmk dot net  2007-05-21 17:01 -------
> (In reply to comment #28)
> > Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var =
> > vi->id instead of rhs.var = id
> >
> > Remove the id variable declaration.
> >
> > This would have only affected fortran ....
>
> thx, this change fixes bootstrap.
> will you commit this for 4.2.1?

Sure.
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #31 from pluto at agmk dot net  2007-06-03 07:21 -------
r125227 | dberlin | 2007-05-31 11:37:38 -0400 (Thu, 31 May 2007) | 11 lines

2007-05-27  Daniel Berlin <dberlin@dberlin.org>

        Fix PR/30052
        Backport PTA solver from mainline

        * pointer-set.c: Copy from mainline
        * pointer-set.h: Ditto.
        * tree-ssa-structalias.c: Copy solver portions from mainline.
        * Makefile.in (tree-ssa-structalias.o): Update dependencies


-- 

pluto at agmk dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pinskia at gcc dot gnu dot org]

------- Comment #32 from pinskia at gcc dot gnu dot org  2007-06-08 23:38 -------
*** Bug 32266 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsberg04+computing dot bugs
                   |                            |dot gcc at ftml dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #33 from pluto at agmk dot net  2007-06-11 13:04 -------
i'm reopening this bug becasue the fix is not complete.

it does fix the xf86ScanPci.i testcase (time/mem hog) and this is great

$ time gcc xf86ScanPci.i -O1 -c  ( 2.2GHz amd64, 1GB ram ).
gcc xf86ScanPci.i -O1 -c  4.10s user 0.20s system 92% cpu 4.665 total

the patch doesn't fix the sipQtCorepart0.ii time hog, only mem hog is fixed.
g++ needs about 300MB of ram and +inf? (canceled after 6 days) of time.


-- 

pluto at agmk dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[rguenther at suse dot de]

------- Comment #34 from rguenther at suse dot de  2007-06-11 13:07 -------
Subject: Re:  [4.2 Regression] possible quadratic
 behaviour.

On Mon, 11 Jun 2007, pluto at agmk dot net wrote:

> 
> 
> ------- Comment #33 from pluto at agmk dot net  2007-06-11 13:04 -------
> i'm reopening this bug becasue the fix is not complete.
> 
> it does fix the xf86ScanPci.i testcase (time/mem hog) and this is great
> 
> $ time gcc xf86ScanPci.i -O1 -c  ( 2.2GHz amd64, 1GB ram ).
> gcc xf86ScanPci.i -O1 -c  4.10s user 0.20s system 92% cpu 4.665 total
> 
> the patch doesn't fix the sipQtCorepart0.ii time hog, only mem hog is fixed.
> g++ needs about 300MB of ram and +inf? (canceled after 6 days) of time.

Can you check where the time is spent on?

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #35 from pluto at agmk dot net  2007-06-11 13:17 -------
(In reply to comment #34)

> Can you check where the time is spent on?

naturally, i'm building gcc with debuginfo now...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #36 from pluto at agmk dot net  2007-06-11 14:04 -------
Created an attachment (id=13677)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13677&action=view)
testcase for time-hog.


-- 

pluto at agmk dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #13043|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[rguenth at gcc dot gnu dot org]

------- Comment #37 from rguenth at gcc dot gnu dot org  2007-06-11 14:08 -------
Looks like it's still PTA:

 tree PTA              : 255.00 ( 0%) usr  17.25 ( 0%) sys 278.07 ( 0%) wall  
28100 kB ( 0%) ggc

(just a snapshot after a few minutes compile)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

------- Comment #38 from pluto at agmk dot net  2007-06-11 14:11 -------
(In reply to comment #34)

> > the patch doesn't fix the sipQtCorepart0.ii time hog, only mem hog is fixed.
> > g++ needs about 300MB of ram and +inf? (canceled after 6 days) of time.

ops little eye damage, the g++ sits on sipQtGuipart0.ii.

> Can you check where the time is spent on?

several backtraces show the gcc sits around solve_graph()...

#0  0x000000000052ef83 in bitmap_elt_insert_after ()
#1  0x000000000052f086 in bitmap_ior_into ()
#2  0x00000000007a33fb in solve_graph ()
#3  0x00000000007a5709 in compute_points_to_sets ()
#4  0x00000000004f3e67 in compute_may_aliases ()
#5  0x0000000000787078 in execute_one_pass ()
#6  0x00000000007871dc in execute_pass_list ()
#7  0x00000000007871ee in execute_pass_list ()
#8  0x00000000004cffee in tree_rest_of_compilation ()
#9  0x0000000000473339 in expand_body ()
#10 0x00000000007cb994 in cgraph_expand_function ()
#11 0x00000000007cc2be in cgraph_optimize ()
#12 0x000000000044116f in cp_finish_file ()
#13 0x00000000004b5cda in c_common_parse_file ()
#14 0x0000000000769083 in toplev_main ()
#15 0x00002b4f81ac6b54 in __libc_start_main () from /lib64/libc.so.6
#16 0x0000000000402459 in _start ()

#0  0x000000000052ef83 in bitmap_elt_insert_after ()
#1  0x000000000052f086 in bitmap_ior_into ()
#2  0x00000000007a1a93 in set_union_with_increment ()
#3  0x00000000007a3b4d in solve_graph ()
(...)

#0  0x000000000052f601 in bitmap_and_compl ()
#1  0x00000000007a33d2 in solve_graph ()
(...)

and some deep trace:

#0  0x00002b4f81b1f95b in memset () from /lib64/libc.so.6
#1  0x00002b4f81b1acd0 in calloc () from /lib64/libc.so.6
#2  0x0000000000893969 in xcalloc ()
#3  0x0000000000719e74 in pointer_set_create ()
#4  0x000000000076b7b6 in walk_tree_without_duplicates ()
#5  0x000000000079ee2f in create_variable_info_for ()
#6  0x000000000079f2a0 in get_vi_for_tree ()
#7  0x000000000079f2fd in get_constraint_exp_from_ssa_var ()
#8  0x000000000079faa5 in get_constraint_for ()
#9  0x000000000079fbbd in get_constraint_for ()
#10 0x00000000007a13f6 in find_global_initializers ()
#11 0x000000000076b1c5 in walk_tree ()
#12 0x000000000076b3fd in walk_tree ()
#13 0x000000000076b3fd in walk_tree ()
#14 0x000000000076b7ca in walk_tree_without_duplicates ()
#15 0x000000000079ee2f in create_variable_info_for ()
#16 0x000000000079f2a0 in get_vi_for_tree ()
#17 0x000000000079f2fd in get_constraint_exp_from_ssa_var ()
#18 0x000000000079faa5 in get_constraint_for ()
#19 0x000000000079fbbd in get_constraint_for ()
#20 0x00000000007a13f6 in find_global_initializers ()
#21 0x000000000076b1c5 in walk_tree ()
#22 0x000000000076b3fd in walk_tree ()
#23 0x000000000076b7ca in walk_tree_without_duplicates ()
#24 0x000000000079ee2f in create_variable_info_for ()
#25 0x000000000079f2a0 in get_vi_for_tree ()
#26 0x000000000079f2fd in get_constraint_exp_from_ssa_var ()
#27 0x000000000079faa5 in get_constraint_for ()
#28 0x000000000079fbbd in get_constraint_for ()
#29 0x00000000007a13f6 in find_global_initializers ()
#30 0x000000000076b1c5 in walk_tree ()
#31 0x000000000076b3fd in walk_tree ()
#32 0x000000000076b7ca in walk_tree_without_duplicates ()
#33 0x000000000079ee2f in create_variable_info_for ()
#34 0x000000000079f2a0 in get_vi_for_tree ()
#35 0x000000000079f2fd in get_constraint_exp_from_ssa_var ()
#36 0x000000000079faa5 in get_constraint_for ()
#37 0x000000000079fbbd in get_constraint_for ()
#38 0x00000000007a13f6 in find_global_initializers ()
#39 0x000000000076b1c5 in walk_tree ()
#40 0x000000000076b3fd in walk_tree ()
#41 0x000000000076b7ca in walk_tree_without_duplicates ()
#42 0x000000000079ee2f in create_variable_info_for ()
#43 0x000000000079f2a0 in get_vi_for_tree ()
#44 0x000000000079f2fd in get_constraint_exp_from_ssa_var ()
#45 0x000000000079faa5 in get_constraint_for ()
#46 0x000000000079fd46 in get_constraint_for ()
#47 0x00000000007a1132 in find_func_aliases ()
#48 0x00000000007a4bef in compute_points_to_sets ()
#49 0x00000000004f3e67 in compute_may_aliases ()
#50 0x0000000000787078 in execute_one_pass ()
#51 0x00000000007871dc in execute_pass_list ()
#52 0x00000000007871ee in execute_pass_list ()
#53 0x00000000004cffee in tree_rest_of_compilation ()
#54 0x0000000000473339 in expand_body ()
#55 0x00000000007cb994 in cgraph_expand_function ()
#56 0x00000000007cc2be in cgraph_optimize ()
#57 0x000000000044116f in cp_finish_file ()
#58 0x00000000004b5cda in c_common_parse_file ()
#59 0x0000000000769083 in toplev_main ()
#60 0x00002b4f81ac6b54 in __libc_start_main () from /lib64/libc.so.6
#61 0x0000000000402459 in _start ()


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[rguenth at gcc dot gnu dot org]

------- Comment #39 from rguenth at gcc dot gnu dot org  2007-06-11 14:15 -------
Created an attachment (id=13678)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13678&action=view)
unincluded testcase

unincluded testcase that also "works" with mainline.  Where the slowness is
also
present.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2/4.3 Regression] possible quadratic behaviour.

[rguenth at gcc dot gnu dot org]

------- Comment #40 from rguenth at gcc dot gnu dot org  2007-06-11 14:17 -------
And again, a 4.2/4.3 regression wrt compile-time _and_ memory-usage.  Mainline
needs 1.2GB ram and whatnot time, 4.1 is happy with 500MB and about 10s.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.1.2
            Summary|[4.2 Regression] possible   |[4.2/4.3 Regression]
                   |quadratic behaviour.        |possible quadratic
                   |                            |behaviour.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2/4.3 Regression] possible quadratic behaviour.

[dberlin at dberlin dot org]

------- Comment #41 from dberlin at gcc dot gnu dot org  2007-06-11 15:40 -------
Subject: Re:  [4.2/4.3 Regression] possible quadratic behaviour.

On 11 Jun 2007 14:17:46 -0000, rguenth at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #40 from rguenth at gcc dot gnu dot org  2007-06-11 14:17 -------
> And again, a 4.2/4.3 regression wrt compile-time _and_ memory-usage.  Mainline
> needs 1.2GB ram and whatnot time, 4.1 is happy with 500MB and about 10s.

Memory usage is just going to be up because we keep the last points-to
sets to propagate only differences.

It will take roughly twice as much memory.

This is just the cost of doing business faster.

I'll work on the time regression.

And please change the summary of this bug to something sane like
"points-to analysis too slow"

The algorithm is cubic in the worst case, and you simply can't do
anything about this.
:)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2/4.3 Regression] points-to analysis slow and memory hungry

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.1                       |4.2.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2/4.3 Regression] points-to analysis slow and memory hungry

[debian-gcc at lists dot debian dot org]

------- Comment #42 from debian-gcc at lists dot debian dot org  2007-07-26 11:20 -------
*** Bug 32900 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2/4.3 Regression] points-to analysis slow and memory hungry

[dberlin at gcc dot gnu dot org]

------- Comment #43 from dberlin at gcc dot gnu dot org  2007-07-26 18:03 -------
On my current branch, which i will commit soon, i have

 tree PTA              :  14.56 ( 1%) usr   0.57 ( 1%) sys  16.98 ( 1%) wall  
26372 kB ( 2%) ggc
 tree alias analysis   : 577.90 (26%) usr   8.72 ( 8%) sys 611.13 (24%) wall 
108272 kB ( 7%) ggc

I have looked through this bug report again, I also don't see PTA taking up
your memory.
(Alias analysis i will try to fix, but it's a bit tricky)

What is happening is the memory is increasing slowly.  It's not like PTA is
suddenly allocating 1.5 gig.
So your memory usage is not coming from PTA (at least, not in a way I can
solve, unless you see a leak somewhere).

It is much more likely someone is leaking memory.

In short I have absolutely no plans to work on the memory hog portion of this 
bug, and deny that points-to analysis is "memory hungry" in 4.3 because i don't
see it.


-- 

dberlin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|memory-hog                  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2/4.3 Regression] points-to analysis slow and memory hungry

[giovannibajo at libero dot it]

------- Comment #44 from giovannibajo at libero dot it  2007-09-11 10:59 -------
Daniel, are you then going to fix the "slow" part of this bug?

As for the memhog, CC'ing Honza which is expert on memory allocations and leaks
:)


-- 

giovannibajo at libero dot it changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2/4.3 Regression] points-to analysis slow and memory hungry

[dberlin at dberlin dot org]

------- Comment #45 from dberlin at gcc dot gnu dot org  2007-09-11 12:58 -------
Subject: Re:  [4.2/4.3 Regression] points-to analysis slow and memory hungry

Uh, it's not slow anymore since I committed the patch last month.


On 11 Sep 2007 10:59:31 -0000, giovannibajo at libero dot it
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #44 from giovannibajo at libero dot it  2007-09-11 10:59 -------
> Daniel, are you then going to fix the "slow" part of this bug?
>
> As for the memhog, CC'ing Honza which is expert on memory allocations and leaks
> :)
>
>
> --
>
> giovannibajo at libero dot it changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |hubicka at gcc dot gnu dot
>                    |                            |org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2/4.3 Regression] points-to analysis slow and memory hungry

[belyshev at depni dot sinp dot msu dot ru]

------- Comment #46 from belyshev at depni dot sinp dot msu dot ru  2007-09-11 19:50 -------
(In reply to comment #45)
> Uh, it's not slow anymore since I committed the patch last month.

Please define "not slow" :)

I stopped compilation of "sipQtGuipart0.cpp" after 2.5+ hours and called
timevar_print (stdout) from gdb:

 tree PTA              : 7383.90 ( 0%) wall  652668 kB ( 0%) ggc
 tree alias analysis   :  550.29 ( 0%) wall 1192023 kB ( 0%) ggc
 tree operand scan     :  178.91 ( 0%) wall   77836 kB ( 0%) ggc

(all other timevars < 10 s)

This is gcc-4.2 r128355. It takes about the same amount of memory (~500 MB) as
4.1 but never finishes.


Unlike 4.2, 4.3 r128377 runs out of memory, and it is much slower than 4.1.
Here is output from timevar_print() from gdb at the time it hit the swap (about
four minutes):

 tree find ref. vars   :   15.88 ( 0%) wall  990776 kB ( 0%) ggc
 tree PTA              :    2.22 ( 0%) wall   23052 kB ( 0%) ggc
 tree alias analysis   :   13.24 ( 0%) wall    8179 kB ( 0%) ggc
 tree call clobbering  :   52.63 ( 0%) wall    2020 kB ( 0%) ggc
 tree flow sensitive alias:    1.28 ( 0%) wall  123311 kB ( 0%) ggc
 tree flow insensitive alias:   21.84 ( 0%) wall       0 kB ( 0%) ggc
 tree memory partitioning:   61.98 ( 0%) wall     870 kB ( 0%) ggc
...
 tree operand scan     :   21.86( 0%) wall  128117 kB ( 0%) ggc

For comparison, 4.1 compiles that file in 50 seconds and takes roughly 500 MB.

(note all timings were done with --enable-checking=release compilers).


-- 

belyshev at depni dot sinp dot msu dot ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |belyshev at depni dot sinp
                   |                            |dot msu dot ru
           Keywords|                            |memory-hog
   Last reconfirmed|2007-03-14 14:21:37         |2007-09-11 19:51:00
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2/4.3 Regression] points-to analysis slow and memory hungry

[dberlin at dberlin dot org]

------- Comment #47 from dberlin at gcc dot gnu dot org  2007-09-11 19:54 -------
Subject: Re:  [4.2/4.3 Regression] points-to analysis slow and memory hungry

On 11 Sep 2007 19:51:00 -0000, belyshev at depni dot sinp dot msu dot
ru <gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #46 from belyshev at depni dot sinp dot msu dot ru  2007-09-11 19:50 -------
> (In reply to comment #45)
> > Uh, it's not slow anymore since I committed the patch last month.
>
> Please define "not slow" :)

I said for mainline
I'm not backporting even more to 4.2.

>
> Unlike 4.2, 4.3 r128377 runs out of memory, and it is much slower than 4.1.
> Here is output from timevar_print() from gdb at the time it hit the swap (about
> four minutes):
>
>  tree find ref. vars   :   15.88 ( 0%) wall  990776 kB ( 0%) ggc
>  tree PTA              :    2.22 ( 0%) wall   23052 kB ( 0%) ggc
>  tree alias analysis   :   13.24 ( 0%) wall    8179 kB ( 0%) ggc
>  tree call clobbering  :   52.63 ( 0%) wall    2020 kB ( 0%) ggc
>  tree flow sensitive alias:    1.28 ( 0%) wall  123311 kB ( 0%) ggc
>  tree flow insensitive alias:   21.84 ( 0%) wall       0 kB ( 0%) ggc
>  tree memory partitioning:   61.98 ( 0%) wall     870 kB ( 0%) ggc
> ...
>  tree operand scan     :   21.86( 0%) wall  128117 kB ( 0%) ggc
>


2.22 seconds is fast.
It only takes 23 meg of memory for PTA.

The rest of your memory usage is not my bug.
The rest of your time usage is not my bug.
If you want to get them fixed, i suggest you file a bug not entitled
"points-to analysis slow and memory hungry".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[dberlin at gcc dot gnu dot org]

------- Comment #48 from dberlin at gcc dot gnu dot org  2007-09-11 19:55 -------
4.3 is no longer a regression as it does PTA faster than 4.1, and uses less
memory.


-- 

dberlin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|4.1.2                       |4.1.2 4.3.0
            Summary|[4.2/4.3 Regression] points-|[4.2 Regression] points-to
                   |to analysis slow and memory |analysis slow and memory
                   |hungry                      |hungry


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[rguenth at gcc dot gnu dot org]

------- Comment #49 from rguenth at gcc dot gnu dot org  2007-10-09 11:44 -------
*** Bug 33708 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fsemkin at yandex dot ru


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[mmitchel at gcc dot gnu dot org]

------- Comment #50 from mmitchel at gcc dot gnu dot org  2007-10-09 19:21 -------
Change target milestone to 4.2.3, as 4.2.2 has been released.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.2                       |4.2.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[jsm28 at gcc dot gnu dot org]

------- Comment #51 from jsm28 at gcc dot gnu dot org  2008-02-01 16:53 -------
4.2.3 is being released now, changing milestones of open bugs to 4.2.4.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.3                       |4.2.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[chkr at plauener dot de]

------- Comment #52 from chkr at plauener dot de  2008-03-12 11:18 -------
(In reply to comment #33)
> it does fix the xf86ScanPci.i testcase (time/mem hog) and this is great

Unfortunately it looks like that the patch it did _not_ fix the mem hog
problem.

I'm compiling the xorg-xserver using gcc 4.2.3 (cross-compiling for powerpc on
x86) and the compiler uses around 1G RAM when compiling xf86ScanPci.c.

I'm not sure about the priority of this problem, but if more information about
my environment are needed to fix it in the 4.2 branch, please ask.


-- 

chkr at plauener dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chkr at plauener dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[rguenth at gcc dot gnu dot org]

------- Comment #53 from rguenther at suse dot de  2008-03-12 12:12 -------
Subject: Re:  [4.2 Regression] points-to analysis
 slow and memory hungry

On Wed, 12 Mar 2008, chkr at plauener dot de wrote:

> ------- Comment #52 from chkr at plauener dot de  2008-03-12 11:18 -------
> (In reply to comment #33)
> > it does fix the xf86ScanPci.i testcase (time/mem hog) and this is great
> 
> Unfortunately it looks like that the patch it did _not_ fix the mem hog
> problem.
> 
> I'm compiling the xorg-xserver using gcc 4.2.3 (cross-compiling for powerpc on
> x86) and the compiler uses around 1G RAM when compiling xf86ScanPci.c.
> 
> I'm not sure about the priority of this problem, but if more information about
> my environment are needed to fix it in the 4.2 branch, please ask.

Whatever problem remains on the 4.2 branch, it is not going to be
fixed there.  Sorry.

Richard.


------- Comment #54 from rguenth at gcc dot gnu dot org  2008-03-12 12:12 -------
Fixed since 4.3.0, WONTFIX on earlier branches.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
      Known to fail|4.2.0                       |4.2.0 4.2.3 4.2.4
         Resolution|                            |FIXED
   Target Milestone|4.2.4                       |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[rguenther at suse dot de]

------- Comment #53 from rguenther at suse dot de  2008-03-12 12:12 -------
Subject: Re:  [4.2 Regression] points-to analysis
 slow and memory hungry

On Wed, 12 Mar 2008, chkr at plauener dot de wrote:

> ------- Comment #52 from chkr at plauener dot de  2008-03-12 11:18 -------
> (In reply to comment #33)
> > it does fix the xf86ScanPci.i testcase (time/mem hog) and this is great
> 
> Unfortunately it looks like that the patch it did _not_ fix the mem hog
> problem.
> 
> I'm compiling the xorg-xserver using gcc 4.2.3 (cross-compiling for powerpc on
> x86) and the compiler uses around 1G RAM when compiling xf86ScanPci.c.
> 
> I'm not sure about the priority of this problem, but if more information about
> my environment are needed to fix it in the 4.2 branch, please ask.

Whatever problem remains on the 4.2 branch, it is not going to be
fixed there.  Sorry.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[rguenth at gcc dot gnu dot org]

------- Comment #55 from rguenth at gcc dot gnu dot org  2008-05-21 14:18 -------
*** Bug 36290 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |naufraghi at develer dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[giovannibajo at libero dot it]

------- Comment #56 from giovannibajo at libero dot it  2008-05-21 15:49 -------
What is the workaround for this bug? It looks like not even -O1 fixes the
compile-time hog.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[rguenth at gcc dot gnu dot org]

------- Comment #57 from rguenth at gcc dot gnu dot org  2008-05-21 15:51 -------
"Fixed since 4.3.0, WONTFIX on earlier branches."

There is no workaround.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[rguenth at gcc dot gnu dot org]

------- Comment #58 from rguenth at gcc dot gnu dot org  2008-05-21 16:05 -------
Note that for 4.3 the testcases are still slow and memory-hungry but not
because
of PTA but because of memory partitioning (we have a PR for that) and because
of call clobber analysis.

 tree find ref. vars   :  15.36 ( 5%) usr   0.80 ( 8%) sys  15.90 ( 5%) wall 
817801 kB (35%) ggc
 tree alias analysis   :  16.27 ( 5%) usr   0.38 ( 4%) sys  16.11 ( 5%) wall  
11037 kB ( 0%) ggc
 tree call clobbering  :  41.35 (14%) usr   0.28 ( 3%) sys  43.00 (14%) wall   
3132 kB ( 0%) ggc
 tree flow insensitive alias:  31.26 (10%) usr   0.34 ( 3%) sys  31.94 (10%)
wall       0 kB ( 0%) ggc
 tree memory partitioning:  83.32 (28%) usr   0.89 ( 9%) sys  84.36 (27%) wall 
   974 kB ( 0%) ggc
 tree SSA incremental  :  10.60 ( 4%) usr   0.17 ( 2%) sys  11.11 ( 4%) wall  
15755 kB ( 1%) ggc
 tree operand scan     :  28.71 (10%) usr   0.57 ( 6%) sys  29.59 ( 9%) wall 
160271 kB ( 7%) ggc


the flow-insensitive analysis part is also interesting (this is the
sipQtGuipart0.cpp testcase).

I will open a new PR to track the general problems with this testcase.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[rguenth at gcc dot gnu dot org]

------- Comment #59 from rguenth at gcc dot gnu dot org  2008-05-21 16:07 -------
-> PR36291.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[giovannibajo at libero dot it]

------- Comment #60 from giovannibajo at libero dot it  2008-06-10 17:26 -------
If a knowledgable GCC developer could suggest *any* workaround at -O1 for this
bug in 4.2 (including disabling whatever alias analysys causes the problem), it
might be proposed as a fix within distros at least.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry

[rguenther at suse dot de]

------- Comment #61 from rguenther at suse dot de  2008-06-11 08:07 -------
Subject: Re:  [4.2 Regression] points-to analysis
 slow and memory hungry

On Tue, 10 Jun 2008, giovannibajo at libero dot it wrote:

> ------- Comment #60 from giovannibajo at libero dot it  2008-06-10 17:26 -------
> If a knowledgable GCC developer could suggest *any* workaround at -O1 for this
> bug in 4.2 (including disabling whatever alias analysys causes the problem), it
> might be proposed as a fix within distros at least.

You can try if --param max-fields-for-field-sensitive=0 improves the
situation.

Other than that, try, in 
tree-ssa-structalias.c:create_variable_info_for remove the
make_constraint_from_escaped and make_constraint_to_escaped calls for
the is_global cases.  Note that you need to adjust find_what_p_points_to
to include escaped variables if escaped_id is set in the solution and
that call clobbering will need similar adjustments (and remember
escaped_id includes all globals implicitly).  The problem with the
sipQt testcase is that it has 10000s of global vars it creates
constraints for, even though they are unused.

Richard. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052