TREE_CODE mania

[Devang Patel <dpatel at apple dot com>]

Hi All,

Recently there was a discussion about faster compile time. And
memory usage and/or allocation is considered one probable
culprit behind the slow compiler.

To understand actual memory usage pattern, I instrumented GCC
by replacing TREE_CODE macro with function TREE_CODE_read().
I just wanted to see what is the usage pattern and how bad/good is it.

I collected profiled data for following one line program.

int foo() { return 1;}

Now, gprof tells me that to compile this, cc1 calls TREE_CODE_read()
37572 times! I was expecting that number to be in couple of thousands
range but 37k seems high to me.

I think, such a high number of indirect memory references puts
high  pressure on VM and GCC's memory manager to maintain locality.
May be we can do simple code reorganizations using few extra
local variables to reduce this pressure. Or may be I am unnecessarily
surprised by this number.

Here is relevant gprof data...

                0.00        0.00     694/37572       _convert <cycle 1> 
[219]
                0.00        0.00     826/37572       _pushdecl [211]
                0.00        0.00     927/37572       _int_const_binop 
[23]
                0.00        0.00    1019/37572       _round_type_align 
[171]
                0.00        0.00    1027/37572       
_darwin_encode_section_info [194]
                0.00        0.00    1155/37572       _layout_type 
<cycle 3> [10]
                0.00        0.00    1306/37572       _tree_size [122]
                0.00        0.00    1499/37572       
_finalize_type_size [28]
                0.00        0.00    1674/37572       _integer_zerop 
[156]
                0.00        0.00    2286/37572       _fold <cycle 1> 
[229]
                0.00        0.00    2304/37572       _make_decl_rtl [16]
                0.00        0.00    3193/37572       _integer_onep [135]
                0.00        0.00    4488/37572       _size_binop [22]
                0.00        0.00    5258/37572       _is_attribute_p 
[101]
                0.00        0.00    6537/37572       _force_fit_type 
[114]
[91]     0.0    0.00        0.00   37572         _TREE_CODE_read [91]

Now in this data size_binop looks interesting. It is expensive and 
according
to gprof it is consuming 16% of total compile time.

[22]    16.7    0.00        0.01    1496         _size_binop [22]

-Devang