This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[tree-ssa] decls in tree-ssa (fwd)
- From: Diego Novillo <dnovillo at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 10 Feb 2003 13:07:36 -0500
- Subject: [tree-ssa] decls in tree-ssa (fwd)
- Organization: Red Hat Canada
Dan sent me this analysis this morning. Both problems are
to be expected: (1) the gimplifier creates a truckload of
VAR_DECLs, (2) the RTL expander is emitting lots of RTL.
Something to keep in mind when we start looking at performance
problems more closely. Right now it's been like shooting fish in
a barrel, and we don't seem to be running out of fish :)
Diego.
----- Forwarded message from Dan Nicolaescu <dann@ics.uci.edu> -----
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Subject: decls in tree-ssa
> Date: Sun, 09 Feb 2003 15:40:20 -0800
> To: dnovillo@redhat.com
>
> Hi!
>
> If you add a
> #define GATHER_STATISTICS 1
>
> at the beginning of tree.c and then use -fmem-report you can get a
> report of the number of trees of different type allocated.
>
> Here are some numbers:
>
> gcc -O1 -fdisable-simple combine.i gcc -O1 combine.i
> String pool String pool
> entries 4251 entries 15171
> identifiers 4251 (100.00%) identifiers 15171 (100.00%)
> slots 16384 slots 32768
> bytes 52k (7431 overhead) bytes 122k (16k overhead)
> table size 64k table size 128k
> coll/search 0.1256 coll/search 0.4676
> ins/search 0.0749 ins/search 0.2233
> avg. entry 12.62 bytes (+/- 6.48) avg. entry 8.28 bytes (+/- 4.70)
> longest entry 41 longest entry 41
>
> ??? tree nodes created ??? tree nodes created
>
> Kind Nodes Bytes Kind Nodes Bytes
> ------------------------------------- -------------------------------------
> decls 9130 1022560 decls 20747 2323664
> types 1500 144000 types 1512 145152
> blocks 311 14928 blocks 311 14928
> stmts 0 0 stmts 1507 44020
> refs 23689 732204 refs 23859 736928
> exprs 72106 2143168 exprs 114389 3508396
> constants 25538 817216 constants 25369 811808
> identifiers 4251 255060 identifiers 15171 910260
> perm_tree_lists 0 0 perm_tree_lists 0 0
> temp_tree_lists 0 0 temp_tree_lists 0 0
> vecs 64 1536 vecs 64 1536
> phi_nodes 0 0 phi_nodes 6971 444872
> ssa names 0 0 ssa names 26163 837216
> random kinds 93905 2629332 random kinds 93855 2627932
> lang_decl kinds 0 0 lang_decl kinds 0 0
> lang_type kinds 0 0 lang_type kinds 0 0
> ------------------------------------- -------------------------------------
> Total 230494 7760004 Total 329918 12406712
> ------------------------------------- -------------------------------------
> Type hash: size 4093, 910 elements, Type hash: size 4093, 911 elements,
> 0.602627 collisions 0.597109 collisions
>
> As you can see when the SSA optimizations are used, the number of
> decls increases by an important amount (and the number of identifiers
> in the string pool).
> Is this to be expected? I am just wondering, maybe there's some low
> hanging fruit here...
>
> Another thing is the RTL generated when using SSA:
>
> wc -l combine.i.00.rtl -> 235816
> when not using the SSA optimizations:
> wc -l combine.i.00.rtl -> 179817
>
> in the SSA case there's a lot of RTL that looks like this:
>
> (barrier 17 16 18)
>
> (jump_insn 18 17 19 (nil) (set (pc)
> (label_ref 21)) -1 (nil)
> (nil))
>
> (barrier 19 18 20)
>
> (code_label 20 19 21 2 "" [0 uses])
>
> (code_label 21 20 23 3 "" [0 uses])
>
>
> I estimate that this type of RTL accounts for about 50% of the size
> increase of the 00.rtl file generated in the SSA case.
> Maybe there's a way to avoid generating this type of RTL...
>
> I thought you might want to know about this stuff.
----- End forwarded message -----